{非技术}如何深入学习C++？
zhy36007
"中国制造",讲述中国60年往事
Fei Yan
The C++ Programming Language / C++ Primier
有个系列书籍叫做，深入c++，如果你是学生并且真的有时间深入C++，花时间看看还是值得的，我看过的大概包括：
=================================================
中级的：Effective C++, More Effective C++, Effective STL;
更深入的（扩展眼界还是很有用）：
Inside the C++ Object Model, Modern C++ Design;
Exceptional C++, More Exceptionanl C++, Exceptional C++ Style;
个人感觉比较实用的：
The C++ Standard Library
Imperfect C++
思想、历史：
The Design and Evolution of C++
The C++ Programming Language
简明精炼的：
C++ Coding Standards
==================================================
这些书未必都值得全看，但除了程序语言之外，周围的知识和土壤可能是更重要的：
1> 操作系统
2> 数据库系统
3> GUI系统的MVC
4> 硬件、汇编
5> 计算机体系结构
如果你想做GUI相关，我觉得还是不要死缠MFC了吧，还不如去学学c#，或者wxWindows/Qt.
Chunyuan Ge
和那本比较 比较实用的：
The C++ Standard Library
其实真的很深入的inside C++ object model读来也没有什么意思， 甚至有可能让你走火入魔陷入语言特性的细节不能自拔
语言么，还是要以使用为先。 一二浅见，海涵。
chuang
个人认为,如果能把<<Effective C++>>中的item都整明白,应付大陆大部分公司的C++工作问题是不成问题的.如果把那些问题都整明白了,对C++的理解也会上一个档次,即使有不会的问题,也可以自己通过看书,搜索解决了.
C++给的很多,最后发现,其实我只是需要这么一点罢了.
--
好装B,不求甚解.
豆瓣:http://www.douban.com/people/Lichuang/
blog:http://www.cppblog.com/converse/
Shuo Chen
我建议你：
1. 把 google protocol buffers 看懂，包括parser和生成的代码，并且把数据格式弄懂。
2. google protocol buffers 有一个RPC的骨架，但是没有提供实现，你可以给libevent做一层C++封装，把
google rpc实现出来。
3. 利用这套rpc，可以写些client/server程序，比如可以从多人在线聊天做起，命令行的就行。
Fei Yan
我当年跟LZ一样,<<C++ Primer>>看了好久.到最后,发现我需要,仅仅是STL,简单的类封装罢了.
个人认为,如果能把<<Effective C++>>中的item都整明白,应付大陆大部分公司的C++工作问题是不成问题的.如果把那些问题都整明白了,对C++的理解也会上一个档次,即使有不会的问题,也可以自己通过看书,搜索解决了.
对这个说法比较赞同
Scott Meyers的三本书可以很快助你登堂入室
不过学生没有写很多程序的情况下，可能进度要慢一些；我是在边写程序的时候，边深入钻研这三本书，花了几个月仔细读完，发觉豁然开朗
之后才能读得懂后边那几本“充满荆棘”的书
C++给的很多,最后发现,其实我只是需要这么一点罢了.
2009/9/22 Chunyuan Ge <hhy...@gmail.com>比较认同 中级的：Effective C++, More Effective C++, Effective STL;
和那本比较 比较实用的：
The C++ Standard Library
这本书的实用价值的确很高，我成买过一本纸制的，可惜太厚了， 后来就弄了个个chm版本的，用firefox查着看
其实真的很深入的inside C++ object model读来也没有什么意思， 甚至有可能让你走火入魔陷入语言特性的细节不能自拔
如果你要读读汇编，查查现代的c++编译器产生的coredump文件，这个是捷径。每次遇到这种事情，基本都是我来干的，周围的同事都感觉我擅长分析那些个程序里直接看不见的东西，其实不过是理解一些Object Model而已。如果想精于调试和排错，这个还是挺有用的
个人感觉，Inside the C++ Oject Model前四章很实用，后边的部分，我第一次没有很弄明白，第二次读的时候，也走马观花一下，印象不深
整体而言，感觉这本书比其它基本 深入系列 的要更偏重使用一点
SpitFire
chuang
SpitFire
--
SpitFire
SpitFire
--
SpitFire
Eric.Wang
需要读的书是《windows核心编程》之类的介绍操作系统的书。因为做C++而不了解操作系统，还不如用C#和Java。做windows界面呢，
《深入浅出MFC》必读，介绍了很多windows的消息机制和渲染机制。
然后是多读代码，特别是优秀的开源代码。学习那些优秀项目的优秀品味和思想。
你想深入学习C++我理解为是为了将来更好的做软件，而不是为了开发新的编程语言。因此没必要陷入太多的晦涩语法里面去。
hu
别的多想也没什么用。
Little Push
Push Chen
SNDA
SDO Project Management Department
Curie Rd. 208
Shanghai, China
Mobile: +8613524446040
Tel: 50504740-1796
Facebook: http://www.facebook.com/littlepush
Twitter: http://twitter.com/littlepush
Li Yang
Lei Yang
Fei Yan
你有大把时间读书的时候，往往缺乏实践的环境和动力；当你对实际的工作搞得焦头烂额的时候，可能时间本身是个稀缺的资源。
我倾向于没有条件的时候，有时间则采取通读，大致有个系统的了解，等到有所困惑的时候，不妨回头再读一遍；
因为之前已经系统看过，那么重读的时候，针对性就会非常强，可以一定程度上缓解上边的矛盾
当时第一次读 Links&Loaders的时候，看的云里雾里但是还是大致过了一遍（因为当时有时间又没有其他的计划），
等到很长一段时间后在迫切需要读这些东西，翻起来就感觉很自然、流畅了，自然也很节约时间
当然我也认为实践中提高才是最实在真切的，读书时候感觉到的提高，容易被证实为是假象，
不过这种假象个人认为不是全无用处，相当于质变之前的量变
Dong Feng
ZangXT
殷远超
Dong Feng
Pink.Bear
sagasw
Dong Feng
2009/9/28 Pink.Bear <mr.be...@gmail.com>:
Dong Feng
从我个人经历看，我待过的公司其实都对Unix的技术要求更高。现在这家对OS
X和Windows的要求一半一半吧。不过我自己还是喜欢花时间在OS X上。工作时间用来学一些Windows也能完成工作。
我不是建议大家不学那些公司需要的知识，那样连工作都不能完成。但是用自己的时间学习的时候，还是花在一些自己有兴趣又有前途的系统上。（另外不用争OS
X，Linux和Windows的前途——虽然我自己兴趣在OS
X，我这篇的重点在QT，GTK和MFC。前两者也都有Windows的port。其实MFC在界面开发上没有什么优势，很多细致的user
experience还是得直接调Win API——这点用QT也能做到。）
2009/9/28 sagasw <sag...@gmail.com>:
sagasw
我的建议是，如果是针对windows开发，MFC是必学的，因为即使到了VC2008，也没有看到开发Team有任何削减MFC的说法，也就是说很长一段时间内MFC仍然是有用的，至于实际相当陈旧，那是陈年旧事，不能总拿着有色眼镜去看。尽管我也不喜欢微软的一些设计风格，但是看到微软的东西立刻就说不好，这种愤青式的评论方式是没什么帮助的。别忘了，微软还有C++两个大牛人。
至于GTK，在Windows平台的界面方面我觉得它还只是个玩具，而QT别忘记它有商业license付费的问题，相比来说MFC是免费的。
关于QT和MFC的对比，Dobbs有篇博客正好讲到，感觉还能客观一些。
http://dobbscodetalk.com/index.php?option=com_content&task=view&id=1657&Itemid=85
sagasw
所以我的回复只针对windows平台上的桌面开发。
如果你有数据可以证明linux桌面开发已经开始占上风，那也欢迎提供。
Dong Feng
微软的技术有历史意义，但是从设计角度说水平很差。以前，微软的优势在于PC需要这样quick and
dirty的方案。如今PC的硬件水平已经和以前的小型机相当了，微软的技术风格的问题就越来越明显。
微软曾经把自己的native GUI放置了三年没有改进，整天鼓吹.NET。弄得ISV们在Windows上无所适从。说它不论技术水平还是技术策略都很混乱不算很主观。微软的牛人也不少，刚有一个Linux的大牛干不下去走人了。还有一个把员工的iPhone拿来戏弄一番的牛人。我是觉得比牛人没什么意义。
至于说MFC和QT的商业开发费用。我只想说你我都不是开公司的（也许你是，那我的话题不针对你的特例）。公司用MFC，你就学MFC（也可以用一些业余时间），这我从来没反对过。但是如果你是凭兴趣学习一些知识，我不建议MFC。个人认为不要觉得MFC免费你以后工作中遇到的MFC开发的几率就一定大，我个人的经历并非如此。
2009/9/29 sagasw <sag...@gmail.com>:
Bill Wung
On 9/23/09, Little Push <littl...@gmail.com> wrote:
> 强烈推荐楼主点开始->运行，输入mspaint然后照着那个东西做一个一模一样的出来，基本上可以算入门了。
--
Sent from my mobile device
笑骂由人，洒脱自如！
心若冰清，天塌不惊！
http://www.iron-feet.cn
cnhenuake
On 9月29日, 下午4时34分, Dong Feng <middle.fengd...@gmail.com> wrote:
> 看到别人批评微软就把别人叫『愤青』并不能体现你的实用主义。
>
> 微软的技术有历史意义，但是从设计角度说水平很差。以前，微软的优势在于PC需要这样quick and
> dirty的方案。如今PC的硬件水平已经和以前的小型机相当了，微软的技术风格的问题就越来越明显。
>
> 微软曾经把自己的native GUI放置了三年没有改进，整天鼓吹.NET。弄得ISV们在Windows上无所适从。说它不论技术水平还是技术策略都很混乱不算很主观。微软的牛人也不少，刚有一个Linux的大牛干不下去走人了。还有一个把员工的iPhone拿来戏弄一番的牛人。我是觉得比牛人没什么意义。
>
> 至于说MFC和QT的商业开发费用。我只想说你我都不是开公司的（也许你是，那我的话题不针对你的特例）。公司用MFC，你就学MFC（也可以用一些业余时间），这我从来没反对过。但是如果你是凭兴趣学习一些知识，我不建议MFC。个人认为不要觉得MFC免费你以后工作中遇到的MFC开发的几率就一定大，我个人的经历并非如此。
>
微软的技术从设计角度来说很差，差在哪里？
举些例子出来？
我先举一个就mfc来说，不能说是最烂的gui框架，也好不到哪去，
首先来说RTT的实现都是靠宏来实现的，还有消息分发，实现的都不怎么好。
整个mfc的代码比较难懂，光一堆宏就把你搞得云里雾里的。
但就是这么烂的框架，相信这里也没人能保证写一个比他好一点的。
cnhenuake
On 9月23日, 下午4时36分, hu <TearOff...@126.com> wrote:
> 公司流行什么就学什么。
> 别的多想也没什么用。
>
呵呵，我们学技术的真正目的是赚钱，养家糊口，当然什么赚钱学什么。
sagasw
但是对你说的这个"整个mfc的代码比较难懂，光一堆宏就把你搞得云里雾里的。"真是不同意,因为我还是读过侯捷的那本书,而且也是看过不少MFC的源代码,从水平上说,我没感觉到什么烂.
最后一句话我同意你,不少人觉得烂,只是他们用的久了,QT就好了么?或者说GTK就是优良设计,根本也没人做个科学的比较.
我最爱说的就是,你不喜欢一件东西的话,再好,那也是不喜欢.
Eric.Wang
而且你说微软的消息分发做的不好，这缺乏依据。因为windows是迄今最成功的桌面操作系统，而windows就是基于你所说的“实现的不怎么好”的
消息分发机制。
你不要轻视了微软的技术实力，好歹也是钱堆出来的。
Fei Yan
我认为MFC的CMapStringToPtr比std::map更好。
一点小小的指正：两个不一样，所以不能比较的。
std::map采用的是binary tree算法，而CMap采用的hash算法，两者的应用场景是有差异的。
既然说出哪个比哪个更好的道道儿来，不妨说说具体的理由，岂不更好？不知道你说的比较对象是否是VC6所带的STL版本？
如果在VC6下，那么MFC的一些基础类据说确实比它配套的STL好用。
如果你认为VC2005/2008的STL也比VC的烂，建议去和Herb Sutter挑一下，我等也可深入学习一下
cnhenuake
我并没有轻视微软的技术实力，相反我是比较尊重的。
就是看到经常有人说微软的技术设计水平差，很想知道一下，到底微软有哪些技术上设计水平差的产品。
也无意说的这么偏激。
sagasw
sagasw
Tinyfool
Windows XP的例子也很类似，如果vista不持续的跳票，发布后对配置要求那么高，XP哪里来的那么久的生命力？
--
Tinyfool的开发日记 http://www.tinydust.net/dev/
myTwitter: http://twitter.com/tinyfool
Dong Feng
Dong Feng
这种想法并不是如你认为的那么理性。如果每个人都明白什么赚钱，银行利率早就是负的了。最好看看Steve
Jobs在Stanford大学毕业仪式上的讲话。选择学习什么，遵从自己的兴趣反而成就会更大。
Dong Feng
我不要求你能对QT和GTK有多了解才能发表观点。但是如果你连这两个库都不了解，就请发表一些贴切的观点，别妄自揣测别人的心理和思维过程。讨论要针对对方的逻辑和事例，而不是胡猜字面上根本看不出来的背景。
2009/10/2 sagasw <sag...@gmail.com>:
Dong Feng
dirty而已。由此说明不了它的消息分发有何优劣。Windows有90%以上的市场占有率，一般在如此高的占有率下只要微软能做到竞争对手的八成，也不会丧失市场。可是看看netapplication的数据，Windows几乎每个月稳定的丧失0.3%的市场。
string没有什么了不起。我待过几个公司用过几个不同的string实现，无非就是查找，拼接，encoding转换而已。一个星期就能自己实现一套。string实现的好不好对于一个中级语言的库来说也就和一辆车的饮料托精致与否一样。（前面有人说批评C++的是在学Linus，下面我就第一次提一下Linus相关的话题。）如果真的发现性能重要，还是必须像Git那样用C的char*操作才能获得deterministic的性能。
2009/10/2 Eric.Wang <wangsh...@gmail.com>:
Dong Feng
微软的技术劣势是相对的，不是绝对的；是现实的劣势，不是说它的技术没有任何历史贡献或者意义。
我不否认，十年前，微软的技术让我能充分使用一台PC，给我带来了很大便利。但是这不意味着，今天当我在Mac上用20分钟就能编译完的工程在Windows上要2个小时，或者我在UNIX上用一个脚本轻松搞定的东西在Windows要折腾好几步鼠标操作，我还必须假装对Windows的技术多么尊重。
2009/10/2 cnhenuake <cnhe...@gmail.com>:
Dong Feng
>
> 而且你说微软的消息分发做的不好，这缺乏依据。因为windows是迄今最成功的桌面操作系统，而windows就是基于你所说的“实现的不怎么好”的
> 消息分发机制。
>
既然起了个头，我就详细聊聊 Windows 的窗口管理。
Windows 的 Window Manager 是 toolkit-aware 的。也就是说，Windows 里很多 control
本身就是一个 window。Window Manager 要分出一些资源来管理这些
control。这样做有很多害处。第一是严重违背了模块之间的 least knowledge 原则；第二是 Windows 的 WM
很大程度还是内核态的，所以这些窗口乃至于 control 的句柄和很多资源都是 system-wide
的。严重的干扰了进程之间的隔离。而且，Windows 依然没有改进对这些 GDI 对象的内存管理。创建大量的 GDI
对象，即使有很多内存可用，也会因为用光 Windows 的一个大小受限的 GDI heap 而导致程序失败。而其它主流的 WM，比如
Gnome（通过GTK），KDE（通过QT）和 Mac OS X （通过 Quartz）都是 toolkit-unaware 的。WM
只处理窗口的状态，对于程序和系统的稳定性以及用户体验都有优势。
GDI 是为了比较低速的 UI 设计的。所以在处理高速应用，比如视频，3D 的时候，Windows 必须采用很多 ad-hoc 的手段。而
toolkit-unaware 的 WM 因为和 toolkit 的交互通过像素进行，所以对所有图像来源一视同仁。这在简化开发和提高 UI
一致性方面有很大帮助。比如 OS X 里的窗口最小化效果，绝对不会因为 content 是静态图片或者视频而有什么区别。而 Windows
下我们经常看到视频和 3D 窗口在这方面的奇怪效果。
Windows 直到 Vista 才开始部分使用显卡的硬件加速来处理窗口。而 OS X 在 XP 之前就开始使用 OpenGL
来处理窗口。而且还支持半透明窗口。到 Windows 7 似乎 Windows 在这方面有所赶上，但是细致程度和稳定性都还有待考验。
另外的小问题还有：
1. 为什么 modal dialog box 弹出之后 parent window 不能 move？如果弹出两层 modal dialog
box，基本上要看 main window 的信息就只能 close 一个 dialog box 重来了。
2. 弹出一个 topmost dialog box 就会 steal focus。如果你刚好输入完一个 text field 准备
enter，你很可能连那个 dialog box 说的什么都没看清就稀里糊涂的 accept 了。
3. 如果你正在拼音输入法里选词， focus is stolen。那么恭喜你，你的 text field 里基本上是一堆垃圾，重新输入吧。
4. 在 Vista 之前，只要你的 Windows app 的消息分发线程被 block，那么你的窗口被覆盖之后就是一个鬼脸。直到
Vista 才开始支持 buffered window。
这些问题 OS X 里都没有。
Bill Wung
several programmers refused to get used to .net because MFC makes them
form a sticky habbit.
On 10/3/09, Tinyfool <tiny...@gmail.com> wrote:
> MFC不是生命力顽强，而是因为后继乏嗣，别跟我说.net <http://xn--mcr800beu5acvb.net>
> 是MFC的后继，现在还继续用MFC的人当然不这么看，这么看的话，他就用.net <http://xn--8mq883a2pt.net>去了。
>
> Windows XP的例子也很类似，如果vista不持续的跳票，发布后对配置要求那么高，XP哪里来的那么久的生命力？
>
> 2009/10/3 sagasw <sag...@gmail.com>
>
>> 如果你在那些大公司呆过（比如IBM），你就会知道有些决定并不是那么简单作出的。
>> 也许程序员也是一边抱怨谁做的这种烂设计，或者是谁写的这些烂代码，一边还是要完成那些烂的设计以及维护那些烂的代码。
>>
>> 也许有的小兵很优秀，但是领导太差劲，那一定不会有什么好的结果。可以看看很多好莱坞的电影都会去塑造那种烂领导搞砸场面，悲情小兵无奈奋斗的狗血场面。（我举一个例子，黑鹰坠落）
>>
>>
>> 另外，当时很多设计都是依赖当时的情境，比如c++标准就是这些，没有那些，那你是程序员能怎么做呢？等着标准出来再写代码，还是通过宏来完成几乎不可能的任务？
>>
>> 我不觉得这是烂，只是微软没有想到MFC的生命力这么顽强。盖茨很早以前也曾经说过，1M的内存足够了（这个典故我有些急不太清楚，大致如此），但是后来的发展大家都知道了，微软也多次想结束windows
>> xp的生命，但是也没有想到，windows xp这个爷爷的生命力甚至超过了windows vista
>> 这个爸爸，弄不好会跟windows7差不多呢，世事无常，就表现在这些事情上吧。
>>
>>
>> 2009/10/2 cnhenuake <cnhe...@gmail.com>
>>
>>
>>>
>>> On 10月2日, 下午2时16分, "Eric.Wang" <wangshaoq...@gmail.com> wrote:
>>> > 我认为MFC的CMapStringToPtr比std::map更好。而且我认为CString虽然烂，但是也比std::string更好。
>>> > 而且你说微软的消息分发做的不好，这缺乏依据。因为windows是迄今最成功的桌面操作系统，而windows就是基于你所说的“实现的不怎么好”的
>>> > 消息分发机制。
>>> >
>>> > 你不要轻视了微软的技术实力，好歹也是钱堆出来的。
>>> >
>>> > On 10月1日, 下午7时46分, cnhenuake <cnhenu...@gmail.com> wrote:
>>> >
>>> > > On 9月29日, 下午4时34分, Dong Feng <middle.fengd...@gmail.com> wrote:>
>>> 看到别人批评微软就把别人叫『愤青』并不能体现你的实用主义。
>>> >
>>> > > > 微软的技术有历史意义，但是从设计角度说水平很差。以前，微软的优势在于PC需要这样quick and
>>> > > > dirty的方案。如今PC的硬件水平已经和以前的小型机相当了，微软的技术风格的问题就越来越明显。
>>> >
>>> > > > 微软曾经把自己的native
>>> > > > GUI放置了三年没有改进，整天鼓吹.NET<http://%E6%95%B4%E5%A4%A9%E9%BC%93%E5%90%B9.net/>
>>> 。弄得ISV们在Windows上无所适从。说它不论技术水平还是技术策略都很混乱不算很主观。微软的牛人也不少，刚有一个Linux的大牛干不下去走人了。还有一个把员工的iPhone拿来戏弄一番的牛人。我是觉得比牛人没什么意义。
>>> >
>>> > > >
>>> 至于说MFC和QT的商业开发费用。我只想说你我都不是开公司的（也许你是，那我的话题不针对你的特例）。公司用MFC，你就学MFC（也可以用一些业余时间），这我从来没反对过。但是如果你是凭兴趣学习一些知识，我不建议MFC。个人认为不要觉得MFC免费你以后工作中遇到的MFC开发的几率就一定大，我个人的经历并非如此。
>>> >
>>> > > 微软的技术从设计角度来说很差，差在哪里？
>>> > > 举些例子出来？
>>> > > 我先举一个就mfc来说，不能说是最烂的gui框架，也好不到哪去，
>>> > > 首先来说RTT的实现都是靠宏来实现的，还有消息分发，实现的都不怎么好。
>>> > > 整个mfc的代码比较难懂，光一堆宏就把你搞得云里雾里的。
>>> > > 但就是这么烂的框架，相信这里也没人能保证写一个比他好一点的。
>>> 我并没有轻视微软的技术实力，相反我是比较尊重的。
>>> 就是看到经常有人说微软的技术设计水平差，很想知道一下，到底微软有哪些技术上设计水平差的产品。
>>> 也无意说的这么偏激。
>>
>>
>>
>
>
> --
> Tinyfool的开发日记 http://www.tinydust.net/dev/
> myTwitter: http://twitter.com/tinyfool
>
--
Dong Feng
2009/10/3 sagasw <sag...@gmail.com>:
Dong Feng
> 说一个更通俗一点的例子，大家应该都经过高考，都经历过所谓的真题练习，如果某个科目你曾经练习过十几年以前甚至几年以前的题目就会发现，靠，这题超简单的，当时的人好幸福啊，做这么简单的题目。
>
> 现在的小孩一般也都会去读个奥数什么的，可我们当时学习不讲奥数这东西，如果让现在一般的小孩“穿越”回去，一定超级容易出名，因为经受的训练不一样，眼界不一样。
>
> 再举个体育上的例子，奥运会世锦赛上百米飞人的成绩频频被牙买加超人打破，可是哪怕三四名的成绩拿到十年前，一样可以得冠军的。
>
> 为什么会有这种现象呢？因为有个词叫作进步，你进步了，看以前的东西自然会觉得不够好，你上网了，自然会觉得父母的眼界好窄。可是这些进步都是基于现在科学的发展社会的发展。但是并不就一定代表爸妈的智力水平情商水平比你差，他们说的话作的事都是基于他们的经验教训学历教育，自然和我们大不一样。
>
说的好，这就叫进步。微软曾经领先，然后PC业（包括Linux，BSD和Mac的广义定义）进步了，微软落后了。
Jeffrey Zhao
Windows为普通用户准备了鼠标，为开发人员提供了自由安装自己需要功能的自由，你放弃了这种自由，然后责怪它对另一大部分群众提供的便利。
Windows是有问题，但也拜托挑点关键的方面和理由，否则就变FUD了。
Jeffrey Zhao
Blog: http://www.cnblogs.com/JeffreyZhao/
> Date: Fri, 2 Oct 2009 17:30:27 +0800
> Subject: [TL] Re: {非技术}如何深入学习C++？
> From: middle....@gmail.com
> To: pon...@googlegroups.com
Hotmail: Powerful Free email with security by Microsoft. Get it now.
Dong Feng
Windows下的命令行，算了吧。配上Cygwin才能勉强对付。
2009/10/3 Jeffrey Zhao <je...@live.com>:
Bill Wung
Dong Feng
2009/10/3 Bill Wung <iron.feet...@gmail.com>:
> 悲剧，该话题在某种程度上又变成了毫无意义的关于windows好和Linux好的论战了~
>
Jeffrey Zhao
至于你后来说MFC之类的，看上去有凭有据的，我不懂所以也不出声了。
Windows自带的命令行是大大不够，但是可以补充cygwin，还能用powershell。
所以我说了，Windows给了你自由让你选择好用的东西。
如果你放弃了自由，那么用不好的话就不要怪别人了。
--------------------------------------------------
From: "Dong Feng" <middle....@gmail.com>
Sent: Saturday, October 03, 2009 3:03 PM
To: <pon...@googlegroups.com>
sagasw
mac的高级是缘于它的显示硬件只需要支持很少几种而已.带来的缺陷也很明显,贵.
说的这个那个的,你可以说它高级,可也不要忽略了市场的选择.感觉你说的一些东西似是而非的,也没必要跟你做这些争论,喜欢不喜欢都是自己的事.
賽no.n
Dong Feng
在Windows下不用命令行不是放弃了自由，是选择不自寻烦恼。在UNIX下花10分钟的代价在Windows上要花一个小时，这样的自由对我太奢侈。
2009/10/4 Jeffrey Zhao <je...@live.com>:
lili
我现在想研究下Tor的设计和源码，为何用的人越多会越慢(据说)？
解决了出口的问题，Big Brother会不会组织0.499元er下载东西摧毁之？
///////////////////// 以下胰岛素分泌偏高者和未成年人慎
入 ///////////////////////////////////
现在怎么跳？
Dong Feng
第一，批评微软＝愤青，说说Mac＝自以为高雅。我希望这样没有水准的逻辑不要出现在TopLanguage上。讨论要基于对方的逻辑和事例，不要按照自己的成见贴标签。如此只能在自己的脑门上显现这些标签。
第二，你说不要『忽略了市场的选择』，这方面我结合netapplication的数据早有论述。我不希望重复。
第三，如果你希望用价格便宜补偿易用性的缺失，这是合理的。但是恰恰说明了价格贵而仍然被市场接受的东西是物有所值的，也就是说人们的投资在易用性方面得到了回报。
第四，Mac的易用性能客观的提高效率。这和主观的喜欢与否不完全是一回事。固然提高效率要看个人的具体情况，但是这不是那种用一句『我就喜欢』就堵人嘴的讨论方法的地方。
第五，感觉别人的言论似是而非要拿出自己的道理。否则要自己好好反思。
第六，Mac是我举的一个方面的例子。我一贯的是说说UNIX。恰好Apple也同意UNIX的先进性。
2009/10/4 sagasw <sag...@gmail.com>:
> 不要以为说说mac就能体现什么优雅高级.
>
> mac的高级是缘于它的显示硬件只需要支持很少几种而已.带来的缺陷也很明显,贵.
>
> 说的这个那个的,你可以说它高级,可也不要忽略了市场的选择.感觉你说的一些东西似是而非的,也没必要跟你做这些争论,喜欢不喜欢都是自己的事.
>
居振梁
只是，我觉得，不了解windows的高级特性而乱抱怨windows太易用的人和没有用过Unix仅仅根据听来的“Unix复杂”而青睐windows的人是同一种性质的，他们就是不愿意去了解，单方面的摆某某功能某某平台也有甚至更好不足以让他们简单的接纳，而且有时候这些功能确实需要借助外力才能实现。
但是换个角度思考，既然借助外力能实现，那不是更好吗？外力能对我产生作用的前提是我自身先能承受啊，要不然我会崩溃的。
前几天才写了一篇文章，小机制反应大思想：符号链接和硬链接。当然写此文并不是为了挑起unix/windows的战争，只是文字还是很自然的就流露出了使用Linux的优越感。后来waterownloo留言说windows xp之前也可以创建硬链接，理由是windows下有原生的UnixUtils，其行为确实跟预期一致（cygwin只是一个模拟层）。
这样不是更好吗？这下Unix用户可以更好的在windows下工作了，当然如果有人偏要抱着偏见不放，那也不能说明Unix/Windows这两个平台的问题。
我回的那贴里我没看到你举任何关键例子，所以我说你说的话不够客观。
至于你后来说MFC之类的，看上去有凭有据的，我不懂所以也不出声了。
Windows自带的命令行是大大不够，但是可以补充cygwin，还能用powershell。
所以我说了，Windows给了你自由让你选择好用的东西。
如果你放弃了自由，那么用不好的话就不要怪别人了。
--
http://wargrey.yo2.cn [黑客精神；团队精神；清心寡欲]
http://juzhenliang.spaces.live.com [自然语言试练场；BY-BLOG]
Jeffrey Zhao
本来就是如此，能够通过轻易补充工具得到高度生产力就是一样，你在Unix下工作不补充任何东西么？
照你的看法，Windows下程序员都不要活了，生产力都是Unix程序员的几分之一。
关键就在于，Windows下程序员自有一套提高生产力的做法，你只是选择了不去接受而已。
--------------------------------------------------
From: "Dong Feng" <middle....@gmail.com>
Sent: Sunday, October 04, 2009 4:03 PM
Jeffrey Zhao
Dong Feng
> 呵呵，感觉赵兄在涉及Unix/Windows立场的问题上比较容易激动。
>
> 只是，我觉得，不了解windows的高级特性而乱抱怨windows太易用的人和没有用过Unix仅仅根据听来的“Unix复杂”而青睐windows的人是同一种性质的，他们就是不愿意去了解，单方面的摆某某功能某某平台也有甚至更好不足以让他们简单的接纳，而且有时候这些功能确实需要借助外力才能实现。
>
>
人的性质太复杂。『就是不愿意去了解』这种心理活动也不好揣测。这里还是把技术问题讲清楚。如果你认为谁谁不了解什么，你就直接讲清楚。如果对方顾左右而言他，那么大家都能看到这个人『就是不愿意去了解』。不要一上来就推测对方的心理。一个技术论坛应该有细致的逻辑推导和实例陈述，而不是对他方的心理做任意的揣测。
>
> 但是换个角度思考，既然借助外力能实现，那不是更好吗？外力能对我产生作用的前提是我自身先能承受啊，要不然我会崩溃的。
>
> 前几天才写了一篇文章，小机制反应大思想：符号链接和硬链接。当然写此文并不是为了挑起unix/windows的战争，只是文字还是很自然的就流露出了使用Linux的优越感。后来waterownloo留言说windows
> xp之前也可以创建硬链接，理由是windows下有原生的UnixUtils，其行为确实跟预期一致（cygwin只是一个模拟层）。
>
> 这样不是更好吗？这下Unix用户可以更好的在windows下工作了，当然如果有人偏要抱着偏见不放，那也不能说明Unix/Windows这两个平台的问题。
>
Unix用户可以在Windows下通过Cygwin工作是一件好事。但是，如果我们是在做一个细致的比较，我只能说Windows+Cygwin的用户体验仍然不如Unix。不否认Cygwin的benifit并不意味着不能对Windown+Cygwin和Unix做比较。这不是什么偏见。这种意见只是说明有一种更好的用户体验在那里，如果你的情况允许可以尽量考虑更好的而不是good
enough的。
居振梁
人的性质太复杂。『就是不愿意去了解』这种心理活动也不好揣测。这里还是把技术问题讲清楚。如果你认为谁谁不了解什么，你就直接讲清楚。如果对方顾左右而言他，那么大家都能看到这个人『就是不愿意去了解』。不要一上来就推测对方的心理。一个技术论坛应该有细致的逻辑推导和实例陈述，而不是对他方的心理做任意的揣测。
那个帖子不是对你说的，
“就是不愿意去了解”是说以前的我和我周围的人。
而且我后面举的例子也就是对此列表的观众中符合上述“推测”的人说的。
顺便分享和广告。
好吧，我主要的问题不是在“对他方的心理做任意的揣测”，而是“想起我曾遇到很多这样的人一时控制不住（可能对那些人的看法也是在揣测）“。其实对于某个话题的讨论，单纯的几句话表述容易一叶障目，尤其当读者掺进心理因素的时候。“人的性质太复杂"，不错，所以对一段非技术上的表述针锋相对实在没有必要，我们不会故意来“揣测”的，你也不会。
Unix用户可以在Windows下通过Cygwin工作是一件好事。但是，如果我们是在做一个细致的比较，我只能说Windows+Cygwin的用户体验仍然不如Unix。不否认Cygwin的benifit并不意味着不能对Windown+Cygwin和Unix做比较。这不是什么偏见。这种意见只是说明有一种更好的用户体验在那里，如果你的情况允许可以尽量考虑更好的而不是good enough的。
看你在本主题前面的回复，你所举的往往也是“我的经验不是如此”，“一个在在OSX上20分钟的事情在windows上要等两个小时”这类没有具体说明的例子，因此这个方面的话题就不继续了。当然这类话题真要细致的来说单纯的“非形式化文字说明”也难辨个所以然，而且你说的是“用户体验”，我说的是“作为操作系统其能力不差”，似乎没有多少交集。对于这两个侧重点，赵兄的话已经说明了：经过这么多年，各方面的需求都早已经被先前的程序员补充完整了。真要对一个具体的点上谈“体验”我觉得没有多少意义，这个点不可能孤立存在。
Dong Feng
比如Visual Studio到2008仍然不支持并行编译。20分钟能在Mac
Xcode上build出来的project在Windows上要一个小时（相同的C++代码）。
至于各方面的需求是否得到补充，我的经历是几乎所有的open source工具都可以直接在Mac OS
X上编译，甚至有很多开源的库，比如zlib，OS X缺省就配制了。相反，很多open source
project都缺少Windows的make
file。事实上，人们在Windows上早就养成了什么都用微软的习惯。几个给Windows编写工具的人不是能和整个UNIX社区抗衡的。
2009/10/6 居振梁 <juzhe...@gmail.com>:
wang feng
>
> 那么拜托举个例子，在Unix下10分钟的代价，在cygwin或powershell里要用一小
> 时的。
sh ~/.bash_history > /dev/null 2>&1
居振梁
这个没有统计过，不知道是不是大家都喜欢用统一的方式来工作（如果在不同的环境下可以选的话），比如喜欢用同一种IDE来开发不同的语言项目；喜欢选择相同的桌面系统来操作不同的Unix；
我这个家伙刚好就喜欢用与环境配套的方式来搞，体现了多样性，比如sun的那套编译器比gnu的慢，但是在solaris上我还是首选sun的编译工具，sun的开发环境。不同的用户选择不同的桌面系统，而且我自己会去找机会尝试不同的选择。因为使用不同的工作环境本身也是一种试炼（同时包括技术、心态、习惯、思维等多个方面）。当然这些都是在任务重要性相同的情况下（其他时候还是会分优先级的）。
一年前，我也是个不知不扣的微软反对者，直到几个月前写OPC服务器的时候，发现用windows的技术我也很乐此不疲。仔细想想也是，windows的技术被我鄙视并不是因为技术本身不行，而是他是由商业驱动的。单纯的技术上的好坏，如果在我的目标上，他不行就不以他为主就是了，这样一来也就能欣然接受了，只是完全没必要（！true==False）。PS：那次的Coding是远程vim的，vs的编辑器没有非关键字补全，太别扭了。
其实还是心态问题，只是被我们转接到了技术上。
有些东西不用是不知道的，从Windows转到Linux再到Mac不是一个单纯情感的决定。
比如Visual Studio到2008仍然不支持并行编译。20分钟能在Mac
Xcode上build出来的project在Windows上要一个小时（相同的C++代码）。
至于各方面的需求是否得到补充，我的经历是几乎所有的open source工具都可以直接在Mac OS
X上编译，甚至有很多开源的库，比如zlib，OS X缺省就配制了。相反，很多open source
project都缺少Windows的make
file。事实上，人们在Windows上早就养成了什么都用微软的习惯。几个给Windows编写工具的人不是能和整个UNIX社区抗衡的。
Dong Feng
2009/10/6 居振梁 <juzhe...@gmail.com>:
missdeer
On Oct 6, 6:06 pm, Dong Feng <middle.fengd...@gmail.com> wrote:
> 有些东西不用是不知道的，从Windows转到Linux再到Mac不是一个单纯情感的决定。
>
> 比如Visual Studio到2008仍然不支持并行编译。20分钟能在Mac
> Xcode上build出来的project在Windows上要一个小时（相同的C++代码）。
>
> 至于各方面的需求是否得到补充，我的经历是几乎所有的open source工具都可以直接在Mac OS
> X上编译，甚至有很多开源的库，比如zlib，OS X缺省就配制了。相反，很多open source
> project都缺少Windows的make
> file。事实上，人们在Windows上早就养成了什么都用微软的习惯。几个给Windows编写工具的人不是能和整个UNIX社区抗衡的。
>
> 2009/10/6 居振梁 <juzhenli...@gmail.com>:
>
> > 2009/10/5 Dong Feng <middle.fengd...@gmail.com>
Dong Feng
我看到的可不是这样，我们公司的大牛们在maillist上讨论的结果也不是这样。不知道是不是同一个VS2008。
2009/10/6 missdeer <miss...@gmail.com>:
Dong Feng
2009/10/6 Dong Feng <middle....@gmail.com>:
SpitFire
--
SpitFire
Jeffrey Zhao
你工作在一个Unix环境下，需要接触的都是Unix项目，Mac就是Unix，自然容易构建。
既然你的工作内容就是Unix环境，这自然没有任何理由让你去用Windows然后再Adaptor一下，生产力自然不高。
如果你接触的大都是Java项目，能够轻易跨平台呢？
我认为，或者说我想讨论的都只是“生产力”这个普遍的，普适的话题，而不是在“特定项目性质”下的讨论。
否则，举个简单的例子，如果你接触的都是Windows项目，你会觉得Mac方便吗？
至于给Windows编写工具的“几个人”和“Unix社区”抗衡不抗衡，我不知道Windows程序员和Unix程序员的数量谁多。
即便是Unix数量多吧，100万对10万，但是就开发环境的质量来说，我还真不觉得10万个人搭出的开发环境会比100万的差。
因为，这是100万对10万，不是100人对10人，我想你应该明白我的意思。
--------------------------------------------------
From: "Dong Feng" <middle....@gmail.com>
Sent: Tuesday, October 06, 2009 6:06 PM
To: <pon...@googlegroups.com>
Subject: [TL] Re: {非技术}如何深入学习C++？
> 有些东西不用是不知道的，从Windows转到Linux再到Mac不是一个单纯情感的决定。
Jeffrey Zhao
你工作在一个Unix环境下，需要接触的都是Unix项目，Mac就是Unix，自然容易构建。
既然你的工作内容就是Unix环境，这自然没有任何理由让你去用Windows然后再Adaptor一下，生产力自然不高。
如果你接触的大都是Java项目，能够轻易跨平台呢？
我认为，或者说我想讨论的都只是“生产力”这个普遍的，普适的话题，而不是在“特定项目性质”下的讨论。
否则，举个简单的例子，如果你接触的都是Windows项目，你会觉得Mac方便吗？
至于给Windows编写工具的“几个人”和“Unix社区”抗衡不抗衡，我不知道Windows程序员和Unix程序员的数量谁多。
即便是Unix数量多吧，100万对10万，但是就开发环境的质量来说，我还真不觉得10万个人搭出的开发环境会比100万的差。
因为，这是100万对10万，不是100人对10人，我想你应该明白我的意思。
--------------------------------------------------
From: "Dong Feng" <middle....@gmail.com>
Sent: Tuesday, October 06, 2009 6:06 PM
To: <pon...@googlegroups.com>
Subject: [TL] Re: {非技术}如何深入学习C++？
> 有些东西不用是不知道的，从Windows转到Linux再到Mac不是一个单纯情感的决定。
Jeffrey Zhao
其实有了Powershell之后，大部分的系统管理工作，开发辅助工作都已经足够了。
当然，完全覆盖unix shell，我不敢这么说。
不过对于那些奇怪的，需要反复执行的任务，那就自己额外写个脚本，甚至写个cmdlet。
Windows下程序员千千万，Windows下的应用程序万万千，
如果你觉得哪个工作不好用，别人也会遇到，在那么长的时间里基本上都有人已经搞定了。
Windows程序员不都是傻瓜，Windows也不是一群白痴做的，
用10年前的观点看现在Windows，有问题的就是我们自己了。
--------------------------------------------------
From: "wang feng" <wanng...@gmail.com>
Sent: Tuesday, October 06, 2009 6:07 PM
To: <pon...@googlegroups.com>
Subject: [TL] Re: {非技术}如何深入学习C++？
>
Dong Feng
2009/10/6 Jeffrey Zhao <je...@live.com>:
Dong Feng
>
> ghy | % {ihy $_.id} > out-null
>
> 其实有了Powershell之后，大部分的系统管理工作，开发辅助工作都已经足够了。
>
> 当然，完全覆盖unix shell，我不敢这么说。
>
> 不过对于那些奇怪的，需要反复执行的任务，那就自己额外写个脚本，甚至写个cmdlet。
>
> Windows下程序员千千万，Windows下的应用程序万万千，
>
> 如果你觉得哪个工作不好用，别人也会遇到，在那么长的时间里基本上都有人已经搞定了。
>
> Windows程序员不都是傻瓜，Windows也不是一群白痴做的，
>
这种间接论证真的很有意思。
>
> 用10年前的观点看现在Windows，有问题的就是我们自己了。
>
10年前的Windows相对当时的情况还不错。今天还不如当初呢。
Dong Feng
> 看这里
> http://msdn.microsoft.com/en-us/library/bb385193.aspx
>
有意思。至少不是原来提及的默认配制。也许我该试着把它加上，不过也许不作为默认配制是有原因的，天知道。
除去并行编译，Windows的开发还有其它方面的问题，而这些问题都是Mac没有的，Linux和大部分Unix也没有大多数问题：
1. API方面，不采用UTF-8，而是采用wchar。结果所有的API都要加一个_w前缀或者w后缀。一开始用wchar是因为UTF-16定长好处理，结果UTF-32出了之后，UTF-16也变成了变长编码。结果既失去了UTF-8对ASCII和char*的兼容，也没得到定长编码的简便性。两头不落。
2. 糟糕的go to definition实现。VC下go to
definition这个操作一旦文件或者sub-project数量较多就会经常失败。明明能编译通过，凭什么就找不到definition呢？没有比较不知道，Xcode下是100%可以成功的。
3. 对路径的限制。Windows的路径还是那个短短的256的限制。更好的是，放到VC里的project经常因为这个问题出一些很有创造力的错误提示。
4. 如果你的代码call stack里面有系统的函数，那么必须到symbol
server上下载symbol才能得到正确的函数名。否则从第一个系统函数往下所有的call stack都是错误的。
SpitFire
--
SpitFire
Dong Feng
> 并行编译，2005是默认打开的，不知道为什么2008改掉了
> 对于你下面说的问题，都是事实，也没什么好辩驳的，不过我相信在unix的世界里也能找到类似的问题，unix下我开发时间不长，只记得函数有_r的版本。然后unix文件系统没有create_time，可能是老黄历了。
> joel的文章说过了，windows与unix是两种文化的产物，一个是程序员友好的，一个是用户友好的，这两种不同的文化当然就会产生不同的产品和工作方式，Mac则融合了这两种文化。
>
对程序员友好最终会反映为对用户友好。正如Neal Stephenson在《In The Beginning It Was Command
Line》里面说的，任何GUI都是一种metaphor，metaphor本身就是一种含糊的东西，如果它所依赖的根基还是一种不清晰的结构，最终总会遇到难以弥补的问题。
UNIX在这个问题上错过了一些时间，也就是上面说的『最终会反映为』的『最终』来的稍有点迟。对此我一贯说对Windows能填补空白的功绩是不可否认的。但是那不意味着发展到今天两种文化没有优劣之分了。
Mac OS X融合了classic
Mac和Unix文化。说Mac融合了Windows和Unix文化有点牵强。因为Windows其实是Mac的一个廉价的clone而已。当然Windows比classic
Mac成功，但是说道融合文化，把Windows说成是Mac融合的一部分就有点不分先后了。毕竟classic
Mac是先出现，而且Apple肯定是更加容易借鉴自家的技术。而且这种融合，是以UNIX为底层基础的。也就是说不是没有主次之分的。
sagasw
第三条
In linux-2.6.11/include/linux/limits.h:
file name */
#define PATH_MAX 4096 /* # chars in a path name including nul */
第四条是不准确的，call stack并不是错误的，只是名字显示不出来罢了。
其他的不想去一一辩驳了，我以前说过，你这些论点都是些似是而非的。
喜欢mac那ok，我也喜欢mac系统，我还有个ibook g4呢，但是把mac上的一切吹到天，就有些过了。
sagasw
第二条，能不能也拿出你的论据呢？比如说xcode支持无限的goto，vc2008不支持之类的。
还是那句话，说话要有论据，不能光用一些似是而非的自定义结论来证明你的看法。
sagasw
但是为何你不喜欢还非要用呢？这就很值得掰扯掰扯了。
Dong Feng
>
> 第三条
>
> In linux-2.6.11/include/linux/limits.h:
>
> #define NAME_MAX 255 /* # chars in a
>
> file name */
> #define PATH_MAX 4096 /* # chars in a path name including nul */
>
> 至于mac系统，我想也应该是有个上限的，比如MAX_PATH宏定义，只是我对mac编程不熟悉，不了解这个值是否定义。
>
> 第四条是不准确的，call stack并不是错误的，只是名字显示不出来罢了。
>
>
你的信息也并不完全。Windows下没有symbol的call
stack显示是错误，而不是仅仅没有名字。这一点可以肯定——我每天都见到因为没有symbol而显示的完全错误的call stack。
>
> 其他的不想去一一辩驳了，我以前说过，你这些论点都是些似是而非的。
>
> 喜欢mac那ok，我也喜欢mac系统，我还有个ibook g4呢，但是把mac上的一切吹到天，就有些过了。
>
>
我还是那句话，我没有把Mac捧上天，也没有把Windows踩下地，但是这二者，或者换个角度，从UNIX和Windows这二者来看，是有优劣之分的。
Dong Feng
> 关于api问题，你不需要考虑是不是用w还是用a，windows其实已经隐藏了这些，何必自寻烦恼呢，而mac和linux，我不知道对应的应该怎么称呼，SDK还是system
> call，但是这个api调用是utf8的，是不应该拿出论据来？
>
fopen() 每个OS都有吧？在大多数UNIX上都是支持UTF-8的。在Windows上你自己去查吧。
>
> 第二条，能不能也拿出你的论据呢？比如说xcode支持无限的goto，vc2008不支持之类的。
>
我不懂你要什么证据。同样的code base在VS种go to
def就失败，在Xcode里就成功，这不是证据吗？奇怪，我原文不是这么写的吗？如此说来你的下一句倒是似是而非了。
>
> 还是那句话，说话要有论据，不能光用一些似是而非的自定义结论来证明你的看法。
>
Dong Feng
> 又想起一个有意思的事情，DongFeng好像对Windows非常不满，其实这种事情很容易解决，不喜欢就不用好了，没有人强迫你。
>
> 但是为何你不喜欢还非要用呢？这就很值得掰扯掰扯了。
>
很简单，没人强迫我的时候我确实不用，我用的时候都是不得已而为之。没有抱怨的意思，只是就二者的优劣评价，供其它想听的人参考。
还是那个意思，你不想听可以不听，觉得我说的不对可以纠正，没必要揣测别人每天的生活如何。
missdeer
2、Visual Assist X，绝大部分时候正确
missdeer
的说法是，天作孽，ooo，自作孽，xxx
On Oct 7, 12:08 pm, Dong Feng <middle.fengd...@gmail.com> wrote:
> 2009/10/7 sagasw <sag...@gmail.com>:
>
>
>
> > 第三条
>
> > In linux-2.6.11/include/linux/limits.h:
>
> > #define NAME_MAX 255 /* # chars in a
>
> > file name */
> > #define PATH_MAX 4096 /* # chars in a path name including nul */
>
> > 至于mac系统，我想也应该是有个上限的，比如MAX_PATH宏定义，只是我对mac编程不熟悉，不了解这个值是否定义。
>
> > 第四条是不准确的，call stack并不是错误的，只是名字显示不出来罢了。
>
> 你的信息也并不完全。Windows下没有symbol的call
> stack显示是错误，而不是仅仅没有名字。这一点可以肯定----我每天都见到因为没有symbol而显示的完全错误的call stack。
Dong Feng
> 1、_tfopen，不过不是UTF-8
>
问题的关键就在于『不是UTF-8』。所以什么_tfopen都是无关紧要。
> 2、Visual Assist X，绝大部分时候正确
>
也许吧，都有一些能对付的方法。但是从out-of-box的角度，从综合的角度，优劣易见。
Dong Feng
> 关于call stack依赖于symbol的问题，我觉得这不能怪ms或vc吧，人家已经提供了这种机制，硬是不用，反过来说它不好不好的，恶毒一点
> 的说法是，天作孽，ooo，自作孽，xxx
>
不在于用不用，能用symbol当然可以用。问题在于fail-over机制也是很重要的。做系统不能all-or-nothing，不能single-point-failure。如果你做的系统只要一点没有配好就整体实效，也能和用户说『自作孽』？
missdeer
而且实际工作中，也是遇得到这种应用场景的，例如我们一个中型项目，一个sln中有约50个vcproj，每次CI时让它在多核服务器上自动
rebuild all，难道不比原来节省很多时间吗
On Oct 6, 8:14 pm, Dong Feng <middle.fengd...@gmail.com> wrote:
> 哦，如果你指多个工程，那毫无意义。我想并行编译的共识是就一个工程来说的。
>
> 2009/10/6 Dong Feng <middle.fengd...@gmail.com>:
>
> > Hammm.....
>
> > 我看到的可不是这样，我们公司的大牛们在maillist上讨论的结果也不是这样。不知道是不是同一个VS2008。
>
> > 2009/10/6 missdeer <missd...@gmail.com>:
missdeer
On Oct 7, 2:33 pm, Dong Feng <middle.fengd...@gmail.com> wrote:
> 2009/10/7 missdeer <missd...@gmail.com>:
wang feng
>
> ghy | % {ihy $_.id} > out-null
这样说来，能够完全克隆unix命令行的powershell完全可以跟linux一样花几个小
时整一个LFS出来了
Dong Feng
X至少都是multi-task的，我们就不用非得用一个并行编译来confirm了。
2009/10/7 missdeer <miss...@gmail.com>:
Dong Feng
stack都是无效的。你的逻辑完全建立在不了解情况的假设上。
2009/10/7 missdeer <miss...@gmail.com>:
missdeer
On Oct 7, 5:14 pm, Dong Feng <middle.fengd...@gmail.com> wrote:
> 讨论工程级的并行意义很小，如果你认为不是毫无的话。因为工程级的并行只要是多任务操作系统都能完成----这就变成讨论操作系统的能力了。既然Windows和OS
> X至少都是multi-task的，我们就不用非得用一个并行编译来confirm了。
>
> 2009/10/7 missdeer <missd...@gmail.com>:
missdeer
我已经很明确说了，"自己的代码总有正确的pdb"，有了这个前提，即使没有第三方dll的symbol，那个会失效吗，既然不失效，能叫整体失效吗，
那时候需要的也是0配置吧？反过来，退一步讲，在0配置时，存在成功的情况，也可以叫做整体失效吗？
On Oct 7, 5:16 pm, Dong Feng <middle.fengd...@gmail.com> wrote:
> 如果你没有遇到过这个问题，就不要在这里纠缠了。怎么叫没有整体失效？从没有symbol的那一点往下都会有错误。如果crash在一个第三方dll里，又没有symbol，整个call
> stack都是无效的。你的逻辑完全建立在不了解情况的假设上。
>
> 2009/10/7 missdeer <missd...@gmail.com>:
Dong Feng
2009/10/7 missdeer <miss...@gmail.com>:
Dong Feng
stack里连你自己的代码都是错误的。还大言不惭『"自己的代码总有正确的pdb"，有了这个前提，即使没有第三方dll的symbol，那个会失效吗』。说你不了解情况有什么冤枉的。
2009/10/7 missdeer <miss...@gmail.com>:
Dong Feng
Windows Call Stack 失效：是指 Call Stack 的全部或者部分（通常是某一点向下）完全混乱。这不是出现在 Linux
或者 OS X 里那种『有 symbol 显示 function name，没 symbol 显示 address』的情况。而是某一点找不到
symbol，以下所有 address 和 function name 都是错误的。
2009/10/7 Dong Feng <middle....@gmail.com>:
missdeer
On Oct 7, 9:14 pm, Dong Feng <middle.fengd...@gmail.com> wrote:
> 你自己的代码能永远不调用第三方的DLL吗？如果crash出现在第三方的DLL里，call
> stack里连你自己的代码都是错误的。还大言不惭『"自己的代码总有正确的pdb"，有了这个前提，即使没有第三方dll的symbol，那个会失效吗』。说你不了解情况有什么冤枉的。
>
> 2009/10/7 missdeer <missd...@gmail.com>:
missdeer
On Oct 7, 9:22 pm, Dong Feng <middle.fengd...@gmail.com> wrote:
> 再补充一下，免得又是一个无谓的回合。
>
> Windows Call Stack 失效：是指 Call Stack 的全部或者部分（通常是某一点向下）完全混乱。这不是出现在 Linux
> 或者 OS X 里那种『有 symbol 显示 function name，没 symbol 显示 address』的情况。而是某一点找不到
> symbol，以下所有 address 和 function name 都是错误的。
>
> 2009/10/7 Dong Feng <middle.fengd...@gmail.com>:
>
> > 你自己的代码能永远不调用第三方的DLL吗？如果crash出现在第三方的DLL里，call
> > stack里连你自己的代码都是错误的。还大言不惭『"自己的代码总有正确的pdb"，有了这个前提，即使没有第三方dll的symbol，那个会失效吗』。说你不了解情况有什么冤枉的。
>
> > 2009/10/7 missdeer <missd...@gmail.com>:
Dong Feng
2009/10/8 missdeer <miss...@gmail.com>:
> 麻烦你回头看清楚关于这个问题的我的第二次回复再来说事
>