程序员孟岩

❶ Linux C++ 服务器端这条线怎么走一年半能做出什么

既然你是在校学生，而且编程语言和数据结构的基础还不错，我认为应该在《操作系统》和《计算机体系结构》这两门课上下功夫，然后才去读编程方面的 APUE、UNP 等书。

下面简单谈谈我对学习这两门课的看法和建议，都是站在服务端程序员的角度，从实用主义（pragmatic）的立场出发而言的。

学习操作系统的目的，不是让你去发明自己操作系统内核，打败 Linux；也不是成为内核开发人员；而是理解操作系统为用户态进程提供了怎样的运行环境，作为程序员应该如何才能充分利用好这个环境，哪些做法是有益的，哪些是做无用功，哪些则是帮倒忙。

学习计算机体系结构的目的，不是让你去设计自己的 CPU（新的 ISA 或微架构），打败 Intel 和 ARM；也不是参与到 CPU 设计团队，改进现有的微架构；而是明白现代的处理器的能力与特性（例如流水线、多发射、分支预测、乱序执行等等指令级并行手段，内存局部性与 cache，多处理器的内存模型、能见度、重排序等等），在编程的时候通过适当组织代码和数据来发挥 CPU 的效能，避免 pitfalls。Modern Microprocessors

这两门课程该如何学？看哪些书？这里我告诉你一个通用的办法，去美国计算机系排名靠前的大学的课程主页，找到这两门课最近几年的课程大纲、讲义、参考书目、阅读材料、随堂练习、课后作业、编程实验、期末项目等，然后你就心里有数了。

学习任何一门课程都要善于抓住主要矛盾、分清主次、突出重点，关键是掌握知识框架，学会以后真正有用的知识和技能，而不要把精力平均分配在一些琐事上。

请允许我再次引用孟岩的观点：http://blog.csdn.net/myan/article/details/5877305
我（孟岩）主张，在具备基础之后，学习任何新东西，都要抓住主线，突出重点。对于关键理论的学习，要集中精力，速战速决。而旁枝末节和非本质性的知识内容，完全可以留给实践去零敲碎打。

原因是这样的，任何一个高级的知识内容，其中都只有一小部分是有思想创新、有重大影响的，而其它很多东西都是琐碎的、非本质的。因此，集中学习时必须把握住真正重要那部分，把其它东西留给实践。对于重点知识，只有集中学习其理论，才能确保体系性、连贯性、正确性，而对于那些旁枝末节，只有边干边学能够让你了解它们的真实价值是大是小，才能让你留下更生动的印象。如果你把精力用错了地方，比如用集中大块的时间来学习那些本来只需要查查手册就可以明白的小技巧，而对于真正重要的、思想性东西放在平时零敲碎打，那么肯定是事倍功半，甚至适得其反。

因此我对于市面上绝大部分开发类图书都不满——它们基本上都是面向知识体系本身的，而不是面向读者的。总是把相关的所有知识细节都放在一堆，然后一堆一堆攒起来变成一本书。反映在内容上，就是毫无重点地平铺直叙，不分轻重地陈述细节，往往在第三章以前就用无聊的细节谋杀了读者的热情。

比如说操作系统，应该把精力主要放在进程管理与调度、内存管理、并发编程与同步、高效的IO等等，而不要过于投入到初始化（从 BIOS 加载引导扇区、设置 GDT、进入保护模式）这种一次性任务上。我发现国内讲 Linux 内核的书往往把初始化的细节放在前几章，而国外的书通常放附录，你可以体会一下。初始化对操作系统本身而言当然是重要的，但是对于在用户态写服务程序的人来说，弄清楚为什么要打开 PC 上的 A20 地址线真的有用处吗？（这不过是个历史包袱罢了。）

再比方说《计算机网络》，关键之一是理解如何在底层有丢包、重包、乱序的条件下设计出可靠的网络协议，这不算难。难一点的是这个可靠协议能达到“既能充分利用带宽，又能做到足够公平（并发连接大致平均分享带宽）”。而不是学会手算 CRC32，这更适合放到信息论或别的课程里去讲。

注意分清知识的层次。就好比造汽车与开汽车的区别，我认为一个司机的技能主要体现在各种道路条件和天气状况下都能安全驾驶（城市道路、高速公路、乡间公路 X 晴、雨、雪、雾），平安到达目的地。作为一名司机，了解汽车运行的基本原理当然是好事，可以有助于更好地驾驶和排除一些常见故障。但不宜喧宾夺主，只要你不真正从事汽车设计工作，你再怎么研究发动机、传动、转向，也不可能比汽车厂的工程师强，毕竟这是人家的全职工作。而且钻研汽车构造超过一定程度之后，对开好车就没多大影响了，成了个人兴趣爱好。“有的人学着学着成了语言专家，反而忘了自己原本是要解决问题来的。”（语出孟岩 快速掌握一个语言最常用的50%）

对于并发编程来说，掌握 mutex、condition variable 的正确用法，避免误用（例如防止 busy-waiting 和 data race）、避免性能 pitfalls，是一般服务端程序员应该掌握的知识。而如何实现高效的 mutex 则是 libc 和 kernel 开发者应该关心的事，随着硬件的发展（CPU 与内存之间互联方式的改变、核数的增加），最优做法也随之改变。如果你不能持续跟进这一领域的发展，那么你深入钻研之后掌握的知识到了几年之后可能反而成为累赘，当年针对当时硬件的最优特殊做法（好比说定制了自己的 mutex 或 lock-free 数据结构）在几年后有可能反而会拖低性能。还不如按最清晰的方式写代码，利用好语言和库的现成同步设施，让编译器和 libc 的作者去操心“与时俱进”的事。

注意识别过时的知识。比方说《操作系统》讲磁盘IO调度往往会讲电梯算法，但是现在的磁盘普遍内置了这一功能（NCQ），无需操作系统操心了。如果你在一个比较好的学校，操作系统课程的老师应该能指出这些知识点，避免学生浪费精力；如果你全靠自学，我也没什么好办法，尽量用新版的书吧。类似的例子还有《计算机体系结构》中可能会讲 RISC CPU 流水线中的 delay slot，现在似乎也都废弃了。《计算机网络》中类似的情况也不少，首先是 OSI 七层模型已经被证明是扯淡的，现在国外流行的教材基本都按五层模型来讲（Internet protocol suite），如果你的教材还郑重其事地讲 OSI （还描绘成未来的希望），扔了换一本吧。其次，局域网层面，以太网一家独大（几乎成了局域网的代名词），FDDI/Token ring/ATM 基本没啥公司在用了。就说以太网，现在也用不到 CSMA/CD 机制（因为 10M 的同轴电缆、10M/100M 的 hub 都过时了，交换机也早就普及了），因此碰撞检测算法要求“以太网的最小帧长大于最大传播延迟的二倍”这种知识点了解一下就行了。

另外一点是 low level 优化的知识非常容易过时，编码时要避免过度拟合（overfitting）。比方说目前国内一些教科书（特别是大一第一门编程语言的教程）还在传授“乘除法比加减法慢、浮点数运算比整数运算慢、位运算最快”这种过时的知识。现代通用 CPU 上的实际情况是整数的加减法和乘法运算几乎一样快，整数除法慢很多；浮点数的加减法和乘法运算几乎和整数一样快，浮点数除法慢很多。因此用加减法代替乘法（或用位运算代替算术运算）不见得能提速，反而让代码难懂。而且现代编译器可以把除数为小整数的整数除法转变为乘法来做，无需程序员操心。（目前用浮点数乘法代替浮点数除法似乎还是值得一做的，例如除以10改为乘以0.1，因为浮点运算的特殊性（不满足结合律和分配率），阻止了编译器优化。）

类似的 low level 优化过时的例子是早年用汇编语言写了某流行图像格式的编解码器，但随着 CPU 微架构的发展，其并不比现代 C 语言（可能用上 SIMD）的版本更快，反而因为使用了 32-bit 汇编语言，导致往 64-bit 移植时出现麻烦。如果不能派人持续维护更新这个私有库，还不如用第三方的库呢。现在能用汇编语言写出比 C 语言更快的代码几乎只有一种可能：使用 CPU 的面向特定算法的新指令，例如 Intel 的新 CPU （将会）内置了 AES、CRC32、SHA1、SHA256 等算法的指令。不过主流的第三方库（例如 OpenSSL）肯定会用上这些手段，及时跟进即可，基本无需自己操刀。（再举一个例子，假如公司早先用汇编语言写了一个非常高效的大整数运算库，一直运转良好，原来写这个库的高人也升职或另谋高就了。Intel 在 2013 年发布了新微架构 Haswell，新增了 MULX 指令，可以进一步提高大整数乘法的效率 GMP on Intel Haswell ，那么贵公司是否有人持续跟进这些 CPU 的进化，并及时更新这个大整数运算库呢？或者直接用开源的 GMP 库，让 GMP 的作者去操心这些事情？）

如果你要记住结论，一定要同时记住前提和适用条件。在错误的场合使用原本正确的结论的搞笑例子举不胜举。

《Linux内核源码情景分析》上分析内核使用 GDT/LDT 表项的状况，得出进程数不超过 4090 的结论。如果你打算记住这个结论，一定要记住这是在 Linux 2.4.0 内核，32-bit Intel x86 平台上成立，新版的内核和其他硬件平台很可能不成立。看完书后千万不要张口就来“书上说 Linux 的最大进程数是 4090”。

一个 Linux 进程最多创建 300 余个线程，这个结论成立的条件是 3GB 用户空间，线程栈为 10M 或 8M。在 64-bit 下不成立。
Reactor 模式只能支持不超过 64 个 handle，这个结论成立的条件是 Windows 下使用 WaitForMultipleObjects 函数实现的 WFMO_Reactor，对于 Linux 下使用 poll/epoll 实现的 Reactor 则无此限制。
C++ STL 的 vector 容器在 clear() 之后不会释放内存，需要 swap(empty vector)，这是有意为之（C++11 里增加了 shrink_to_fit() 函数）。不要记成了所有 STL 容器都需要 swap(empty one) 来释放内存，事实上其他容器（map/set/list/deque）都只需要 clear() 就能释放内存。只有含 reserve()/capacity() 成员函数的容器才需要用 swap 来释放空间，而 C++ 里只有 vector 和 string 这两个符合条件。

最后一点小建议，服务端开发这几年已经普及 64-bit 多核硬件平台，因此在学习操作系统的时候，可以不必太关心单核上特有的做法（在单核时代，内核代码进入临界区的办法之一是关中断，但到了多核时代，这个做法就行不通了），也不必太花精力在 32-bit 平台上。特别是 32-bit x86 为了能支持大内存，不得已有很多 work around 的做法（困难在于 32-bit 地址空间不够将全部物理内存映射入内核），带来了额外的复杂性，这些做法当时有其积极意义，但现在去深入学似乎不太值得。

关于项目，我出两个练手题目：

一、多机数据处理。有 10 台机器，每台机器上保存着 10 亿个 64-bit 整数（不一定刚好 10 亿个，可能有上下几千万的浮动），一共约 100 亿个整数（其实一共也就 80GB 数据，不算大，选这个量级是考虑了 VPS 虚拟机的容量，便于实验）。编程求出：
1. 这些数的平均数。
2. 这些数的中位数。
3. 出现次数最多的 100 万个数。
*4. （附加题）对这 100 亿个整数排序，结果顺序存放到这 10 台机器上。
*5. （附加健壮性要求）你的程序应该能正确应对输入数据的各种分布（均匀、正态、Zipf）。
*6. （附加伸缩性要求）你的程序应该能平滑扩展到更多的机器，支持更大的数据量。比如 20 台机器、一共 200 亿个整数，或者 50 台机器、一共 500 亿个整数。

二、N-皇后问题的多机并行求解。利用多台机器求出 N-皇后问题有多少个解。（注意目前的世界纪录是 N = 26，A000170 - OEIS ）
1. 8 皇后问题在单机上的运算时间是毫秒级，有 92 个解，编程实现之。
2. 研究 N-皇后问题的并行算法，写一个单机多线程程序，争取达到线性加速比（以 CPU 核数计）。再设法将算法扩展到多机并行。
3. 用 10 台 8 核的机器（一共 80 个 CPU cores），求解 19-皇后和 20-皇后问题，看看分别需要多少运行时间。你的方案能否平滑扩展到更多的机器？
*4. （附加题）如果这 10 台机器的型号不一，有 8 核也有 16 核，有旧 CPU 也有更快的新 CPU，你该采用何种负载均衡策略，以求缩短求解问题的时间（至少比 plain round-robin 算法要好）？

你可以用 Amazon EC2 或 Google GCE 来验证你的程序的正确性和性能，这两家的虚拟机都是按小时（甚至更短）收费，开 10 台虚拟机做一个下午的实验也花不了多少钱。

❷ 有人超越C++之父吗

C ++ 的 背 影
——C++之父Bjarne Stroustrup印象 左轻侯 2002.11.4
热爱C++的朋友请不要误会，我并不是在暗示“C++已经日薄西山”，或者任何类似的意思。从语义上来说，C++作为一门编程语言，当然不会有什么背影。事实上，我想说的是一个人的背影。因此这个题目显得有点突兀，甚至哗众取宠。但是我想，在C++社群中，每一个人都会同意，有一个名字就是C++的象征。这个名字当然就是Bjarne Stroustrup。
Bjarne Stroustrup博士，1950年出生于丹麦，先后毕业于丹麦阿鲁斯大学和英国剑桥大学，AT&T大规模程序设计研究部门负责人，AT&T 贝尔实验室和ACM成员。1979年，Stroustrup开始开发一种语言，当时称为"C with Class"，后来演化为C++。1998年，ANSI/ISO C++标准建立，同年，Stroustrup推出其经典着作The C++ Programming Language的第三版。
2002年10月，Stroustrup首次访问中国。
接触IT界的时间越长，我就越明显地发现，那些曾经在媒体上喧嚣一时的话题，往往只是些无关紧要的事情，而真正有着深刻意义和影响的大事，却很容易默默无闻。
Stroustrup的访华，在技术圈子里引起了很大的轰动。多少年来，中国的程序员一直通过翻译的着作这样的间接渠道（往往滞后时间很长），在黑暗中辛苦摸索。直到互联网普及之后，我们才能够通过网络在第一时间追踪最新的技术，与国外的同行进行技术交流，慢慢地、一步步地拉近与世界的距离。今天，我们终于有机会当面请教这位世界级的大师，直接聆听这个领域中最权威的声音。我们再也不用费尽心思去琢磨蹩脚翻译背后的作者的思想，不用迷惑于那些经常出自于一知半解的专家之口、不知道经过多少次转述、真伪难辨的惊人之论了。在得知Stroustrup访华的消息之后，我就和一些朋友谈到，这是一个开始，希望中国的技术界能够契此机会，依靠大家的努力，与国际上的技术社群建立稳定的交流机制，希望这件事标志着中国的程序员们不再是一个孤立、被国际社会遗忘的群体，真真正正成为世界大家庭的一员。
不过，除了主办方做的一些宣传之外，Stroustrup的到来，几乎没有见诸于任何主流媒体，虽然Stroustrup的成就和对计算机界的影响力，足以与当代任何一个人相比，虽然这次事件的意义，远远超过许多国内IT圈子里的鸡毛蒜皮。
Stroustrup的这次访华，行经北京、西安、杭州、上海四个城市，时间长达半个月。在此期间，我有幸见过他三次。
第一次是他刚刚到达北京的第二天，华章的两位朋友请他在北海后门的一家饭店吃饭，留了一个机会给我和他共进晚餐。我至今对北京的堵车痛恨无比，因为那天正好是周末，加上大雨，我竟然比预定的时间晚了一个多小时到达目的地。当我气急败坏地冲进那家饭店时，一眼就看到，在最靠里面的角落里，华章的两位朋友中间，坐着一位老外。
他站起来，很有礼貌地和我握手。他本人和那张着名的照片（在C++社区中尽人皆知）上的样子很象，有点秃顶，衣着随便，与其说是一位来中国访问的专家，不如说是一个在自己家中随意进餐的蓝领。我用英语结结巴巴地解释了迟到的原因，他点着头“哦”了好几声，一副“理解理解”的样子，仿佛他也曾深受堵车之苦。虽然我们素昧平生，但对方的神情和简单的几句话，却一下子拉近了我们的距离。这句话听起来象书上的套话，但身临其境的我，却的确有这样的感觉。
在这次见面之前，我曾经想象过Stroustrup会是一个什么样的人，会不会比较高傲。因为我知道，大凡超群绝伦的人物，往往在性格上都有一些偏执，何况以C++之父的身份？但是和我想象的完全相反，Stroustrup非常和善，具有技术人员特有的那种极佳的幽默感，很爱笑，甚至可以说有点天真。当我说了一句倾慕的话之后，他居然会象个孩子一样不好意思。
饭店里很吵，其实不是谈话的好地方。我的口语水平本来就不好，大学毕业后又荒废了好几年，但是面对Stroustrup，不知为什么，我居然勇气百倍，用这种洋泾滨英语连说带比划，跟他说了一些事情。我告诉他，我翻译过他的一个关于C++的风格与技术的FAQ，而且正在阅读他的名着《C++程序设计语言》；我告诉他，中国有很多C++程序员，大家期待他的到来已经很久了；我告诉他，中国的程序员缺乏与国外社群的交流，希望我们能够推动这种交流；我还为自己的口语水平而道歉（BS很理解地回答英语也不是他的母语），希望能够通过Email交流……
然后Stroustrup用一连串低沉的英语作为回答，但并不是那种严肃的学术性的发言，而是说得很随意，也很投入，显然他在打动别人之前先打动了自己。说得精彩之处，他会左顾右盼，然后和我们一起开怀大笑。
这是一家普通的饭店，菜也是很普通的菜。BS和北京街头随处可见的老外并没有多少区别。说着说着，我突然有一种冲动，我想，这些坐在我们旁边自顾自高谈阔论的人，会不会知道角落里这个谈笑风生、自得其乐的老外，就是一位震铄当代的大师，一位为人类做出过伟大贡献的人？
“人和人，真的是很不一样……”我想。
由于BS明天一早还要赶飞机去西安，所以我们相聚的时间相当有限。出了店门，我们挥手告别。我的收获是BS在《C++程序设计语言》中文版上的签名和一张合影。
回到家里，整个夜晚我都在房间走来走去。同租的室友问我：“你今天好象很激动啊？”
“当然，”我回答说，“因为我见到了这个领域的巅峰。”
Stroustrup的行程是先到北京安顿，然后飞往西安，按照西安-北京-杭州-上海这个顺序进行正式访问。在等待Stroustrup回北京的时候，我在csdn上看到了一个贴子：《Bjarne Stroustrup在西安的讲座很令人失望》。点进去看，倒不是对讲座的内容失望，而是批判举办活动中的一些现象，这也正是我最担心的。其实我知道举办方作出了很大努力，有些技术上的问题情有可原，对于这次事件本身来说，算不得什么大不了的事情。但是触动我的是，文中说到Stroustrup演讲完以后，听众们提问的情况。贴子的原文如下：
“……那位主持人在宣布开始提问后，就走了出去，之后混乱的场面就开始了，我坐在地板上听了几个问题，大多是问C++、C#、java哪门语言更好之类的问题，这些人可能并不了解Bjarne Stroustrup，他本人早都说过不会对语言的优劣进行评述，可这些人还是不停的问，甚至还有人问Bjarne Stroustrup，在计算机和自己的女朋友当中他更喜欢哪一个？是不是更喜欢计算机？这种问题，我不想作什么评论，好好的机会，就这样......唉！！我可以明显的看到Bjarne Stroustrup的脸上有不悦的表情。在看到前面的人越聚越多，并开始拼命的想抢到话筒的时候，我决定还是早点离开为妙，我从地上站起身来,拍拍身上的尘土，大踏步的离开了。”
我以前并没有和Stroustrup打过交道，也不知道他对中国的印象如何。我曾猜想过，Stroustrup是如何看待中国的？是不是把我们当作一个遥远的蛮荒之地来看待，就象我们看待非洲某个小国一样？如果真是这样，那也一点都不奇怪，毕竟中国在国际上的形象是一个IT市场，而不是一个IT领跑者。当然随便进行这种猜测是不礼貌的，但是那也要我们能够赢得人家的尊敬才行。当得知有见到Stroustrup的机会时，我和朋友曾经互相勉励：“不要丢中国程序员的脸啊。”
一年多以前，我曾对朋友说过：“这几年中国程序员的水平是长进了很多，以前是不知道自己水平有多差，现在是知道自己水平有多差了。”IT技术的核心在国外，我们开放国门的时候也并不长，水平比不上人家，是没有办法的事情。知道自己水平差以后，无非是两点，一是要承认现实，二是要想办法追赶。
进入计算机这个行业以来，我已经见过了无数自以为或被人以为是高手的妄人，种种气焰无庸详说，尽管在Stroustrup面前他们连学生的资格都远远够不上。中国到底有多少人在使用C++？有多少人对C++有深入全面的了解（虽然我知道水平高的人肯定是有的）？我们的民族软件产业，到底是由一群什么人在支撑？
期待中的大师终于来了，期望中的face-to-face的交流场面也终于出现了，面对显示器屏幕，我突然有一种莫名的孤独苍凉的感觉。
第二次见到Stroustrup，也是在饭店里，由我作东，北京的几个程序员朋友和他进行一次小范围的交流。该死的历史又一次重演了，又是周末，又是大雨，我又一次迟到了。不同的是，当我再次气急败坏地冲进饭店时，看到了不同的场景。Stroustrup一个人坐在桌子的一边，左右座位都是空的，其他人坐在他的对面，大家都不说话，只有他一个人在默默地吃东西。他好象已经习惯了我的迟到，问了我一句：“You got lost?”
也许是受到了这种气氛的影响，我坐在他旁边的时候，一时居然不知道应该说什么好。虽然我很想为他在西安的遭遇说几句道歉的话，但又开不了口。
他拿起手头的一份英文报纸，指着上面的Texas大学对我说：“A small world.”原来他已经受聘担任Texas大学的教授了。我问：“Then you leave AT&T?”他说AT&T仍然保留了他的位置。我还问过他关于Lippman加入微软担任VC.net首席架构师的事情，与我的预料不同，他似乎对微软的编译器评价很高。
但是总的来说，这一次Stroustrup比上一次要沉默得多，很少发笑，大多数时候都在默默吃东西。我终于忍不住，问了一个也许不太礼貌的问题：“Do you feel lonely in China?”Stroustrup没有听明白“lonely”这个词，当他弄明白了之后，很严肃地说：“No.”他指指对面，又指指外面，说（当然是用英文）：“他们，还有很多人，他们都给了我很好的待遇。”“希望中国能给您留下一个好印象。”“现在就已经是这样了。”但愿如此。
吃完饭后，Stroustrup去宾馆接受一家媒体的采访。我和几个朋友继续聊天。虽然他们和我一样，因为口语水平的限制，没有能和Stroustrup畅所欲言，但是兴奋之情都溢于言表。有一位还嚷嚷着要去报考Stroustrup的研究生，虽然后者说他已经收到了数以千计的application。
在白石桥的人行天桥上，望着黑暗的天空下来来往往的车流，我对一个朋友说，我为Stroustrup感到不平。象比尔·盖茨、拉里·埃利森这种人访华，都会享受国宾级的待遇，媒体上也会铺天盖地地宣传。Stroustrup无论从成就还是从影响力上来说，都和他们是一个层次的，为什么他的中国之行会这样朴素、低调、默默无闻？对方略作思考后回答，因为盖茨和埃利森都身为大商业公司的首脑，可以直接影响中国的市场和政府。而Stroustrup虽然发明了C++和实际掌握着C++语言的标准，但他对业界的影响并不那么直接，他本人也不是有钱人。我说：“这个我也知道，但我还是为他感到不平。”
Stroustrup在1979年发明C++语言，至今已经二十多年，一直在为C++的完善、发展和标准化而奋斗。在在Stroustrup的理想中（也是他一直在不懈提倡的），C++应该是一种中立的、开放的、不依赖于任何平台的、不被任何一家商业公司所操纵的语言，它的标准掌握在ISO C++标准委员会中。在这一点上，C++和Delphi与Java这样的语言有着本质的区别。
虽然C++出现得很早，但是它的ISO标准经过千锤百炼，迟至1998年才正式出台。Stroustrup不满商业公司为了自己的利益，把C++变成各种乱七八糟的方言，花了很多心血在C++的标准化工作上面。在来自世界各地的志愿者们的共同努力下，新的C++标准和标准库都已经臻于完美。从这个意义上来说，Stroustrup创立的不仅仅是一种语言，而是一种文化。Stroustrup成功了（C++也许是当前使用最广泛的通用工业语言），但他仍然有很多事情要做。Stroustrup的这次中国之行，可以看作是他和他的理念与中国软件界的一次正面接触。从我看到的情况来说，至少中国软件界的气氛，与Stroustrup浑身上下的气质并不那么相投。
网上有一个所谓IEEE对Stroustrup专访的文章，很明显是一个愚人节笑话，内容是Stroustrup宣扬他故意将C++设计得难以学习，是为了提高程序员的薪水。不知哪位好事之徒把它译成了中文，导致了我几乎在常去的每一个论坛（包括非技术性的论坛）上都发现了这个东西的转贴（有时还是一而再再而三的转贴），底下跟着一大堆煞有介事的评论。在后来的通信中，我把这个事告诉了Stroustrup，他显然当成了笑话来听，回答说：“It doesn't matter as long as they don't believe it.”
我该怎么回答他，告诉他其实大家都信以为真？
最后一次见到Stroustrup，是在北京大学的一个C++语言研讨会上。前一天在清华的演讲我没有去，据说相当成功。北大的这个研讨会是内部性质的，规模不大，实行凭证入场的方式，应该是保证了参与者的质量。与会的还有几位重量级的人物，包括《C++程序设计语言》的译者、北大的裘宗燕教授，另外慕名而来的估计也不少。
我无论如何不能再迟到了，提前一个小时到了会场。我刚到，就陆陆续续有人进来了，一边互相打听着“C++之父的研讨会是不是在这里”。很多人带着Stroustrup着作的各种版本，估计是来寻求签名的。终于，Stroustrup在华章公司和北大计科系的人的簇拥下出现了，今天他看起来精神不错。
首先是Stroustrup做了一个题为《Speak C++ Like a Native》（将C++作为一种母语）的演讲，概要地说明了C++的设计思想和几种编程风格。内容比较基础，而且在西安交大和清华做的演讲也是这个，我没有太在意。接下来是由举办方邀请的人进行比较正式的发言，裘宗燕第一，熊节第二，我排在第三个。我提的是一个关于通过C++语言开发跨平台程序的问题，询问C++为什么没有一个象Delphi那样的跨越平台的framework，以及将现有的标准库是否有往这方面发展的意向。这个问题发挥的弹性很大，可以详细讨论，也可以几句话带过去。但是Stroustrup象回答前两个问题一样，非常详尽和耐心地做了回答，从C++的目标和定位说起，谈到标准库和商业公司的专有库的区别，谈到因为资金问题标准库不太可能发展成为包罗万象的framework，最后建议我可以尝试一些比较优秀的第三方库。在说话的时候，Stroustrup一直注视着我的眼睛，不断打着手势，认真得让我有愧疚的感觉，因为我的理解往往跟不上他的言锋。
最精彩的是自由答问时间，很多人都已经跃跃欲试了。我已经无法详细地回忆起当时的具体情形，总之发言非常踊跃。在我的印象中，似乎没有出现特别有创意的问题（当然在这种即兴发言中，很难出现这种好问题），不过大多数的问题都有相当的水平。其实不用听他们问的内容，只需要看到那一张张神情专注而略显紧张的年轻的脸，就能够让人产生一种熟悉而亲切的感觉……毋庸讳言的是，其实有不少问题纯属浪费时间，因为类似的问题Stroustrup早已经回答过许多次了，在网上稍微查找一下就能找到答案。这种情况应该可以从一个侧面说明，中国程序员作为一个整体，与国外的交流还是太少了，仍然缺乏放眼世界的胸襟和眼光。
“Stroustrup真可怜，被人一遍又一遍地问这些同样的问题，”负责陪同Stroustrup的一位朋友忍不住嘀咕说，很容易想象，这种场面他已经见过好多回了。尽管如此，Stroustrup仍然不厌其烦地解答着每一个问题，认真得让人想起近代历史上的传教士，这份耐心真是让我佩服无己。很显然，今天他兴致很高，特别是遇到了good question的时候，发挥的时间远远超过了预定的期限。几个小时的热烈讨论，让Stroustrup已经略显疲态，后来不得不背靠着墙壁说话（不知为何，他就是不愿意规规矩矩地坐着，整个自由答问期间都是采用站立的姿势，甚至常常用一只脚踩在椅子上）。但是当主持者向他示意时间已到，可以结束时，他却摇手反对，表示要继续讨论下去。现场发出了一片善意的笑声……
晚饭由北大的一位副教授做东，作陪的有华章的几位编辑，C-View的孟岩和王昕，科泰的陈榕。陈榕在微软工作过多年，英语很好，和Stroustrup聊了很长时间，谈的是业界的一些事情，基本上没有涉及技术问题。
曲终人散，我们走出北大的校门，Stroustrup将在第二天飞往上海。临上车之前，他很严肃地和我们中的每一个人握手道别，并表示感谢。不知中国之行带给他的是什么？但我知道，他带给我们有很多，包括以后建立的联系。在北京的夜色中，这个年过五十、头发已经稍微有些花白的丹麦人转身离去，留下一个沉默的背影。

再见，Stroustrup。

❸ java是谁发明的

十大事件与Java相关的四十个名字

1990－1994：Java缘起
文/孟岩

Larry Wall说，优秀程序员应有的三个特点:懒惰、急躁和傲慢。Java就是诞生在一群懒
惰、急躁而傲慢的程序天才之中。
1990年12月，Sun的工程师Patrick Naughton被当时糟糕的Sun C++工具折磨的快疯了。
他大声抱怨，并威胁要离开Sun转投当时在Steve Jobs领导之下的NeXT公司。领导层为了
留住他，给他一个机会，启动了一个叫做Stealth（秘密行动）的项目。随着James
Gosling等人的加入，这个项目更名为Green。其目标是使用C++为嵌入式设备开发一种新
的基础平台技术，James Gosling本人负责开发一个SGML编辑器。正如人们事后分析的那
样，这位天才的程序员太懒惰，所以没有把C++学好，开发中碰了一头包;太急躁??所以
不愿意停下来读读Scott Meyers的新书《Effective C++》;太傲慢??所以轻易地决定开
发一中新的编程语言。他把这种语言命名为C++++--，意思是C++“加上一些好东西，减
去一些坏东西”。显然这个糟糕的名字不可能长命百岁，很快这种颇受同伴喜爱的小语
言被命名为Oak。
到了1992年9月，Oak语言连同Green OS和一些应用程序一起发布在称做Start 7的小设备
上，从而使之有了第一次精彩的亮相。随后，Sun开了一家名为FirstPerson的公司，整
个团队被转移到这家公司里研发机顶盒，以投标时代华纳公司的一个项目。这帮天才被
技术狂热所鼓舞，开发出了一个高交互性的设备，结果没想到时代华纳公司和有线电视
服务商并不愿意用户拥有那么大的控制权，从而在竞标之战中败给了SGI。Oak的锋芒之
锐，竟然把客户都给吓懵了。Sun沮丧地关闭了FirstPerson，召回了整个团队。事实证
明，传统行业中那些脑满肥肠的保守主义者是腐朽没落的。回去！回到激情澎湃的IT产
业，抓住互联网的大潮，这才是出路！1994年，Oak被命名为Java，针对互联网的新一轮
开发如火如荼，一切已经就绪，熔岩在地下奔流，火山即将喷发。

1995: Java香浓世界
文/马伟

1995年，Sun正式对外公布了Java，并且发布了JDK 1.0。这种外形酷似C++，却包含一颗
Smalltalk般纯洁的面向对象之心的全新程序设计语言及其平台，几乎在一夜之间就成为
软件产业的新宠儿。Java当时仅仅被用来为网站制作一些动态应用,诸如动画图片之类，
但这仍然引起了很多Web开发者们的注意，他们非常渴望有一种安全的语言，可以在静态
的HTML网页上制作动画图片。Sun最终把Java集成到NetScape浏览器。同时因为它具有
“只写一次，随处运行”的特性，而引起了很多开发者的注意，他们可以再也不用为了
使程序能够在不同型号的硬件上运行而耗费大量的时间来编译代码了。
当时的Web浏览器的出现也为Java的出现起到了很好的推动作用，通过Java和Web浏览器
的结合，人们似乎看到了什么，有人甚至预言PC将在一两年内退出历史的舞台，取而代
之的是基于Java的浏览器应用程序，通过网络计算设备来进行应用。Java的出现为当时
的软件产业带来了无限的遐想。

1996：Java大跃进，盟主地位就此定
文/马伟

SUN在1996年一开始首先成立了JavaSoft组织，并在1月23日正式发布自己的Java 1.0，
作为20世纪业界出现的最重要的技术之一，Java引起了编程世界的革命。直到现在，
Java仍然是互联网上最流行的语言。
在Sun正式发布Java 1.0之后，Java这门新生的语言就拥有了自己的会议??JavaOne，这
次会议初试啼音就吸引了600多名参与者。除了拥有这么多的积极参与者来进行Java的开
发之外，各大知名公司也纷纷向Sun申请Java的许可。一时间，NetScape、惠普、IBM、
Oralce、Sybase甚至当时刚推出Windows 95的微软都是Java的追随者。
Java的应用就像是世界上的顶级玩家们组成的一个公开联盟，告诉全世界我们大家就是
都在用着Java。也正是因为如此，Java也找到了自己的归宿。现在的J2EE已经成为中大
型企业级应用的标准，成为承接数据库和Web之间的一个重要桥梁。
当年Java的机会实在太多了，以至于很难知道到底该做什么。最终Java在应用服务器市
场获得了难以取代的地位，也确定了J2EE的发展方向，并且仍将延续下去。

1997-2001: 微软与Sun的Java官司
文/孟岩

Java诞生的1995年，正是微软在软件产业地位达到巅峰的时代，Windows 95发布时的风
光场面给人们留下的深刻印象至今难忘。尽管如此，作为最卓越的技术领袖，比尔?盖茨
仍然敏锐地注意到Java。当他了解了Java的一些细节之后，给予了这样的评价:“Java是
很长时间以来最优秀的程序设计语言。”基于此，微软于1996年3月申请并获得了Java许
可证。微软对于Java的这一热情态度在当时大大提高了人们对Java的兴趣和信心，但也
有不少人担心微软会依靠自己强大的影响力在标准之外另立标准，从而破坏Java的纯洁
性。
果然，从1997年发布Visual J++的第一个版本开始，微软就开始在Java中掺入自己的私
有扩展。这毫无疑问引起Sun的高度重视。1997年10月，Sun向美国加州地方法院起诉微
软公司违反两公司就微软使用Java技术所签定的合同，指控微软公司在自己的Java产品
中做了“不恰当的修改”，违反了合同中承诺向用户提供Java兼容产品的条款。这一官
司旷日持久，直到2001年1月双方达成和解，微软将继续提供采用Sun开发的Java技术的
现有产品（包括测试版）。不过，Sun有限制地仅对包括Java 1.1.4的微软产品提供许
可。到了2001年7月，微软公布新版的Windows XP将不再支持Sun的JVM，并且推出了.NET
平台与Java分庭抗礼。
现在回过头去看，当时的这一场官司对Java世界产生了深远的影响。如果没有这一场官
司，也许很多Java程序员都在使用Visual J++，基于WFC开发Windows客户端程序，同时
不得不面对被两个不同的事实标准所分裂的Java世界。

❹ 如何学好C++

程序员》推荐C++ 图书三人谈

主持人：熊节（透明），《程序员》杂志编辑，C-View成员
嘉 宾：孟岩（梦魇）,联想公司掌上设备事业部应用开发处任职，C-View成员。与侯捷先生合译《C++ Standard Library》一书
金尹（恶魔），上海天宇公司CTO，在《程序员》连载有“自由与繁荣的国度”系列文章

透明：“学C++用哪本书入门”，这是被问得最多的一个问题。但是哪一本书是最好的入门书？似乎很难找到答案。《C++ Primer》太厚，《Effective C++》对读者要求比较高，《Essential C++》又常常被批评为“太浅”。
其实说穿了：no silver bullet。想从一本书学会C++，那是不可能的。有朋友问我如何学C++，我会建议他先去找本数据结构书，把里面的习题全部用C++做一遍，然后再去看《Effective C++》。myan经常说“要在学习初期养成好习惯”，我对此颇不以为然。
个人认为，《Essential C++》适合作教材，《C++ Primer》适合作参考书，《Effective C++》适合作课外读物。

恶魔：很后悔当初买了《C++ Primer》。因为从我个人角度来看，它的功能效用基本是和《The C++ Programming Language》重合。当然对于入门来说，它还是很不错的。但是《C++ Primer》太厚，一来导致看书极其不方便，二来系统学习需要花比较长的时间。对于目前这个越来越快餐化的时代来说，的确有很多不适合的地方，不过可以作为初学者的参考书。现在我以一块K3 CPU的代价把它借给了别人，希望我那位同事能够从中得到一些益处。
如果已经具备了C基础，我建议看国内的书，例如钱能的《 C++大学教程（第二版） 》。(如果没有C的基础还是看谭浩强的C语言)。这本书对C讲得还算比较清晰，有很多习题值得一做，特别是最后的struct和union两个部分。其中的一些算法比较拖沓和繁琐（比如树和链表的遍历算法），读者可以尝试修改这些例子，作为最后对C语言的一些总结测试。

梦魇：这个问题让我想起四五年前的情形。今天对于C++有一点认识的人，多半是从那几年就开始学C++了。那时根本没有品牌观念。从书店里找一本C++书，如果看着还算明白，就买下来。我记得那时候宛延闿、张国锋、麦中凡教授的书都受到很高的赞誉。我个人最早的一本C++书是Greg Perry的一本书，今天想起来，其实是一本打着C++旗号的C语言教程。对我作用最大的一本书是国防科技出版社出版的一本书，书名记不得了，作者叫斯蒂芬·布莱哈。
透明：还记得以前曾批评过一本C++书，是北航出的，整本书就没有出现过class关键字。那本书，说穿了其实只是介绍了C语言和iostream库的用法，根本不能算C++。而当时我常常推荐的一本书是电子科技大学张松梅老师的C++教程。那本书，直到今天来看也没有太大的问题，唯一的缺憾就是由于年代久远，许多东西已经过时了。而对于一本技术书籍来说，“过时”是最不可接受的。
总体来说，那时使用C++的人真是在“盲人摸象”。不过这也有好处，就是对C++的很多细节能搞清楚，以后看到经典好书时比较容易理解；当然坏处就是概念不清，甚至都不知道C++和Visual C++、Borland C++到底有什么不一样。

梦魇：整个90年代，其实大部分人对于C++的认识都似是而非。一开始是等同于Borland C++，后来是等同于Visual C++和MFC。所以一般来说，打着BC和VC旗号的书卖得很好，人们觉得这就是C++。而我比较幸运，布莱哈的那本书虽然从现在的眼光来看谈不上高超，但基本路子是对的。可能是因为原书是给UNIX程序员的培训教材，所以没有让我一开始就形成“C++ == VC++”的认识。
其实一直到1996年，我们那里搞计算机的都是唯Borland C++马首是瞻的，到了VC 4.0出来，一下子格局全变了。1997年VC5推出之后，书店里MFC书铺天盖地，学MFC的人，头抬得都比别人高一些。不过现在看来，那时候大部分的MFC书都是三流货色。我曾经有一段时间认为，那一批程序员中间有不少被误导了。根本原因就是相对的封闭。

透明：我觉得一本书的价值有两方面：第一，教给你实用的技术；第二，促使你去思考。对于一本介绍VC（或者说MFC）使用方法的书，我根本不希望它能促使我有什么思考，所以我就一定要求它在技术上精益求精完美无瑕。我刚开始用VC的时候，买的第一本书就是潘爱民老师翻译的《VC技术内幕》（第四版），没有受到那些“三流货色”的误导，应该说是很幸运的。

梦魇：1999年机械工业出版社开始出版“计算机科学丛书”，其中的《Thinking in C++》第一版受到了广泛的欢迎。其实我一直不认为这本书很出色，虽然拿过一次大奖。然而我们都得承认，这本书在C++书籍领域里第一次建立了品牌观念，很多初学者开始知道，不是随便买哪一本都一样的。再往后就是2000年的《 深入浅出MFC（第二版） 》第二版，以及侯先生在《程序员》上发表的那一篇《C++/OOP大系》，加上整个大环境的变化，品牌观念深入人心，C++书籍市场终于开始逐渐与世界同步。
回想往事，我的感觉是，那个需要战战兢兢选择入门书的时代已经过去，今天的C++初学者，大可以放心地买口碑好、自己读起来思路顺畅的书，入门不再是太大的问题。还有一些程序员已经学了几年C++，但看到今天出版的一些新书，感觉比较陌生，这也不是什么问题。侯先生经常说“凡走过必留下足迹”，所谓“走弯路”，未必不是一件好事。
至于具体的推荐表，就不好一概而论了。总之在我的印象里，《Essential C++》、《C++ Primer》、钱能教授的C++教程，都不错。甚至有人一上来就看Bjarne Stroustrup的《The C++ Programming Language》，只要他喜欢，也没什么不可以。

透明：我同意你的观点。不管怎么说，编程是门实践性非常强的学问。要想对C++对象模型有深入的了解，最好的办法就是写一串程序去看结果；要想学会OOP，也只能从项目中学。对于初学者，最好的学习方法就是不停地写程序，写真正有用的程序，写到有问题的时候就去查书，于是自然就会知道哪本书好哪本书不好。不过我们的教育制度能不能让大学里的学生们有这样的学习机会，我表示怀疑。
以我的经验，学C++有两个门槛：入门和使用。完全看不懂C++，这是一个门槛，但是只要有一本合适的入门书，很快就能跨过。要想真正用上C++，却不是件很容易的事情。尤其对于学生来说，接触到的东西多是“玩具”，很难有实战的机会。所以经常看见有人问“C++到底能做什么”，这是C++学习中一个比较麻烦的问题。我们都是做了相当长时间的C++程序之后才看到一些真正经典的书，也正是因为走了相当长的弯路之后才知道这些书的经典之所在。所谓弯路，我想也是一种必须的积累。就算一开始就看《Essential C++》和《C++ Primer》，没有两三年的时间恐怕还是难有所得。

恶魔：有两句十分有道理的话，一是我大学的C语言老师说的“写程序不如说是抄程序”，另一句是一网友说的“好的设计来自借鉴，天才的设计来自剽窃”。对于我这个理性批判主义者来说，这两句话的确不太适合。但是无论从哪个角度来讲，对于初学者来说，剽窃大师的作品是通向成功的最快捷径。
我个人认为，对于C++的初学者来说，首先要确定自己专业领域内主要使用的特性的方向。因为C++的特性如此众多，初学者想贪多基本是不可能成功的。C++的编程范式基本可以分为ADT+PP、GP和OO三个方向。对于ADT+PP范式来说，初学者的主要问题不是学习C++，而是学习C的使用。对于这样的初学者，国内的几本书还是写得比较清楚，符合中国人的习惯，比如谭浩强的《C语言教程》、钱能的《C++语言大学教程》。这两本书我首推第一本，因为这一本我潜心研究了一年，这本书当中很多程序是可以剽窃的，而且可以对这些程序进行加工和提升。比如结构这一章中，它所给出的用struct来实现链表、二叉树的算法是相当蹩脚的。学习ADT+PP的初学者将这本书揣摩透以后可以尝试修改这两个程序。另外这本书的第二版稍微涉及了一些关于“类”的内容。学习ADT+PP的初学者，可以不被OO中的一些专有特性扰乱自己的思路，对于类层次扁平、无继承、无多态的程序编写是有很大好处的。

透明：你好象比较推崇国内教授写的书。现在社会上有种不好的风气：一捧就捧上天，一贬就贬下地。就好象对待谭教授的书，前几年是奉为经典，这几年又有很多人使劲批评。学C++更是有点“崇洋媚外”，总是觉得初学就应该看《Essential C++》。我看这种观点也是片面的。

恶魔：当然《Essential C++》也值得看看。但是我个人觉得这本书没有谭浩强的《C语言教程》来得好。主要原因是：第一，C++的所有特性都点到了，但是不深，看了以后会三心二意没有方向；第二，可以抄袭借鉴的例子太少。《C语言教程》中有很多有趣的问题，比如猴子吃桃、汉诺塔等等，这些例子对于刚刚涉及C/C++语言编程的人来说是学习编程很好的例子。《Essential C++》只能是前两本书看透以后，作为学习C++特性的一个过渡性的书籍。让读者真正领略到什么是C++的编程、和C编程的不同点在哪里。

透明：我发现一个很有趣的现象：初学者往往喜欢问“哪本书比较好”，这让我很是不解。这有点像一个刚学打篮球的人问“王治郅和科比谁比较厉害”。当然科比更厉害一些。但如果你是想学打篮球，这两个人都非常非常有资格教你，你跟谁学都能学得很强——关键不是在于你选哪个老师，而是在于你自己用多少功夫去学。

透明：回到原来话题。学会了C++的语法，能看懂C++代码之后，必须有些书来指导进阶（或者叫指点迷津）。我觉得《设计模式》很好，能够让读者看到一些精妙的用法。不过正如我经常说的，模式带来的麻烦和好处一样多，甚至麻烦还要更多。而且，C++本身的问题使得在C++中使用GoF模式愈加麻烦。

梦魇：《Design Patterns》这本书绝对是不可以没有的，而且中英文版都不可少。最初我看中文版，说实话看不懂，但是也不觉得人家翻译得不好，所以就想，大概是原文就很难懂，加上自己水平有限。于是总是想着再找几本patterns的书来看。后来找到几本书，口碑还不错，不过水平高下，一比就出来了，还是那本《Design Patterns》最经典，最耐看。英文版出来之后，两个版本对照看，明白多了。现在觉得，其实就设计模式来讲，把这本看明白了就很不错了，不用再花费很多心思找其他的书。我现在的包里始终夹着这本书，随身携带，有备无患。
至于说设计模式的副作用，和可能带来的弊端，我的体会也挺多。不过是这样，我们想一想，究竟什么情况下设计模式可以用得很好呢？一种是有经验丰富的人引导，比如要是Robert Martin带队，你在某个地方用错了设计模式，他就会指出来，说这里不对，将来会产生什么样的弊端。对于他来说，丰富的实践经验足以支持他进行“预测型”设计。但是大部分人没这个能力，因此我们只好走第二条路和第三条路，就是“试探型”设计和“重构型”设计。遇到一个问题，你觉得用某种模式挺合适的，就大胆地用了，成功是积累经验，发现不好，出了问题了，只好改回来，那也是积累教训。这叫做“试探型”。至于重构，应该算是最有组织、成功率最高的工程化方法。先把问题“quick and dirty”地解决了，所有的暗礁都暴露出来，然后再根据实际情况采用合适的模式优化设计。现在XP和UP都高度重视refactory，UP在Elaboration和Construction阶段都鼓励抽出专门的iterations进行重构。所以说如果组织快速的软件开发，当然比较倾向于这条路——打成功率嘛。

透明：讲到重构，我顺便说说《Refactoring》这本书的影响。从工程本身的角度来说，你所谓的“重构型设计”是没有什么问题的。但中国的开发者（也包括我在内）往往比较冲动，比较容易相信银弹的存在。曾经有那么一段时间，我在Java中尝试过了重构的方法之后，又拿到C++中去尝试。结果发现，在Java中速度非常快的重构过程，到C++中就被减慢了。究其原因，就是因为C++和Java的约束条件不同。拿着Java中成功的案例直接套C++，不失败才怪。
所以，我必须说：《Refactoring》这本书很有价值。但对于C++程序员来说，它的价值是让你思考，思考这种方法的可行性。如果一个C++程序员没有打算迁移到Java，那么我必须告诉他：《Refactoring》这本书不是让你照着它用的，甚至不是让你去相信它的。对于C++程序员，《Refactoring》全书可以放心相信的只有第13章，其他的部分，都必须非常谨慎地对待。

梦魇：我还要就“试探型”的方法多说两句，我觉得对于个人发展来讲，“试探”也是必不可少的，撞墙不可怕，高水平的人不都是撞出来的吗？你失败了一次，就知道这个模式有什么潜在的问题，下次再用，就会多看几步，像下棋似的。撞的多了，路数就出来了。
我不知道你们是否有这个感觉：用错了模式，吃了亏，再回过头去翻翻《Design Patterns》，看到人家早就指出来这个问题，不过就是那么几句话，原来看上去干巴巴的，现在觉得句句都讲到心坎上，GoF的形象马上就高大起来，还带着光环，感觉是既兴奋又懊悔。

透明：现在回头来看，我更欣赏myan推荐给我的《Designing Object-Oriented C++ Applications Using Booch Method》。这本书能够帮助C++程序员理清思路培养习惯，可惜国内没有引进。相比后来商业味浓厚的UML系列书籍，我觉得这本书对于面向对象的阐释精辟独到，至今未有能出其右者。

梦魇：刚才我们两人都说到Robert Martin，他可是我的榜样。那本1995年的《Designing Object Oriented C++ Application》，我觉得是每一个C++软件工程师都应该反复研读的书。可惜不仅国内没有引进，在国外的名气也不大。如果你觉得面向对象的那些道理你好像都明白，可就是一遇到实际问题就使不上劲，那这本书就是你的最佳导师。
提到理清思路，还有一本书不得不提，就是Andrew Koenig的《Ruminations On C++》。每个人都应该问自己，我学了这么多年的C++，究竟什么是C++最基本的设计理念？遇到问题我第一个直觉是什么？第一个试探型的解决方案应该具有那些特点？如果你不能给出明确的答案，就应该认真地去读这本书，读完了你就有了“主心骨”。

透明：插一句话，谈谈“推荐书”的问题。入门书基本上是放之四海而皆准的，所以推荐的意义也不大。而入门后的发展方向，每个人不同，这个时候就需要“高人”的指点。举个例子：我学C++的时候，myan还不认识我，所以也没有给我推荐书，我还是学过来了，所以即使你当时向我推荐了《Essential C++》或者《C++ Primer》，我也不会太感谢你；但在我认真研究OO的时候，你推荐Robert Martin那本书给我，对我帮助就特别大，而且我从别的地方也很难找到类似的推荐，所以我就很感谢你。
一个程序员，必须有framework的意识，要学会用framework，还要主动去分析framework（在这方面，《Design Patterns》能有一定的帮助）。但是，真正高质量、成气候的framework的书恐怕也就只有针对MFC的。从这个角度来说，MFC纵有千般不是，C++程序员都非常有必要先去用它、熟悉它、研究它，甚至借助《深入浅出MFC》这样的书来剖析它。不然，很难有framework的意识和感觉。
当然，另一个framework也很好，那就是STL。不管用不用MFC、STL，对这两个东西的掌握和理解都是极有帮助的。最近我又在看《深入浅出MFC》，虽然已经不用MFC编程了，但帮助是一定有的。

梦魇：MFC和STL方面，我还是比较推崇侯先生的两本书《深入浅出MFC》和《STL源码解析》。
《深入浅出MFC》这本书，名气自然是大得不得了，不过也有不少人批评。其实书也没有十全十美的，批评当然是少不了的，不过有的时候我看到有人评论这本书，把它跟Inside VC相比，真的是牛头不对马嘴。
你刚才其实说得很对，程序员应该有一点framework意识。而这本《深入浅出MFC》与其说是在讲MFC编程，不如说通篇是在拿MFC为例分析Application Framework的架构和脉络。所以无论你对于MFC本身是什么态度，这本书对每一个C++程序员都有很大的益处。

透明：是的。《VC技术内幕》会告诉你“DYNAMIC_CREATE这个宏怎么用”，《深入浅出MFC》则告诉你“DYNAMIC_CREATE这个宏是怎么实现的”。所以，如果你只需要在VC下写一些小应用程序，《深入浅出MFC》的价值并不太大；但是，如果你需要设计一个稍微大一点的东西（不一定是framework），MFC的设计思想就会有所帮助。

梦魇：另外，我觉得对于MFC也应该有一个公允的评价。过去是吹捧得天上有地下无，书店里铺天盖地都是MFC的书，搞得大家只知有MFC，不知有C++，甚至直到现在还有人问：“我是学MFC呢，还是学C++？VC++是不是比C++更高级的语言？”MFC成了一尊神像，阻碍了人们的视线。所以得把它从神坛上拉下来。这就是过去一两年有很多人，包括我在内批评MFC的一个目的。可是现在大家视野开阔了，.NET也出来了，MFC不再是神像了，少数人就开始以贬损MFC为乐了。我觉得这种态度是不对的。
什么叫好的框架？我觉得在十几年的时间能够象MFC这样保持稳定并且不断进步的框架就是好的框架。可能我们在一些具体的设计问题上有不同看法，觉得“这个地方这么设计不是更漂亮吗？”很多时候是的，但是这不重要，重要的是MFC成熟稳定、有十几年的成功经验，这是最了不起的东西。
另外一点，MFC中间包括着学习Win32 API编程的最佳资料。这是除了其framework方面之外的另一个亮点。我现在使用Win32 API开发，但是经常参考MFC的源代码，收获很大。

透明：STL方面，我对于剖析它的源代码兴趣并不大，毕竟里面源代码多是算法问题。所以，《STL源码剖析》我也只是随便翻翻就束之高阁了。我觉得这本书用来做计算机系的数据结构和算法教材不错，不知道有没有老师乐意这样做。
对于STL，我的态度一向都是“应用至上”。不过，我一直认为SGI STL本身就是一本精彩的书，一本数据结构和算法的经典参考书，同时也是泛型技术的参考书。想知道一个算法是如何实现的，看看STL源代码就行；想知道如何使用type traits，STL源代码里面也有例子。看别人写的书，总觉得隔着一层纱，有点挠不到痒处的感觉。SGI STL的代码写得非常漂亮，一个C++程序员如果不看看这本书，实在是可惜。

梦魇：至于STL，除了《STL源码解析》之外，我举贤不避亲，强烈推荐侯先生与我合译的那本《The C++ Standard Library》。这本书质量之高是无需怀疑的。我现在手边常备此书，随时查阅，对我帮助很大。

透明：C++和Java相比，最大的优势就是它没有一个专门的公司来管它，最大的弱点也是它没有一个专门的公司来管它。Java程序员在学会简单的语法之后，立刻进入SUN提供的framework，一边用这个现成的framework做实际开发，一边在开发过程中继续学习Java一些幽深的特性。而这个时候，C++程序员恐怕还在问“VC和BCB哪个好”呢。这无疑是浪费时间。

梦魇：刚才你说Java和C++的优劣，这个话题已经成了我们这个年代永不消失的声波了。我也不想再谈这个。不过有一点我得说清楚：现在我们很多用C++的人吃了不少苦头，探过脖子去看看Java，觉得它真是太可爱了，这种印象是不准确的。另外，Java也不简单，而且会越来越庞大复杂。在很多场合，Java还不具有竞争力。至于将来如何，我看有些Java爱好者也过分乐观了，似乎计算机科学界几十年解决不了的问题都可以借着Java的东风解决掉，恐怕没那么容易。

透明：那当然。我再次强调：No Silver Bullet。读书很重要，但古人说“行万里路，读万卷书”，还是把“行路”放在“读书”前面。尤其对于技术书籍，如果它不能帮我解决问题、不能给我带来非常实际的利益，那么我是不会去读它的。恶魔说得对，我们这个社会很快餐，我们这个行业尤其很快餐，我们也只能努力适应它。
另外,站长团上有产品团购,便宜有保证

❺ 零基础自学c语言需要看什么书

零基础自学c语言需要看什么书
其实具体看哪一本书并不重要，你可以看大学教材，但是重要的是要坚持，而且这个光看是看不会的，要自己动手多多实践。

❻ C++算法求精，看看谁的算法最优

程序员》推荐C++ 图书三人谈

主持人：熊节（透明），《程序员》杂志编辑，C-View成员
嘉 宾：孟岩（梦魇）,联想公司掌上设备事业部应用开发处任职，C-View成员。与侯捷先生合译《C++ Standard Library》一书
金尹（恶魔），上海天宇公司CTO，在《程序员》连载有“自由与繁荣的国度”系列文章

透明：“学C++用哪本书入门”，这是被问得最多的一个问题。但是哪一本书是最好的入门书？似乎很难找到答案。《C++ Primer》太厚，《Effective C++》对读者要求比较高，《Essential C++》又常常被批评为“太浅”。
其实说穿了：no silver bullet。想从一本书学会C++，那是不可能的。有朋友问我如何学C++，我会建议他先去找本数据结构书，把里面的习题全部用C++做一遍，然后再去看《Effective C++》。myan经常说“要在学习初期养成好习惯”，我对此颇不以为然。
个人认为，《Essential C++》适合作教材，《C++ Primer》适合作参考书，《Effective C++》适合作课外读物。

恶魔：很后悔当初买了《C++ Primer》。因为从我个人角度来看，它的功能效用基本是和《The C++ Programming Language》重合。当然对于入门来说，它还是很不错的。但是《C++ Primer》太厚，一来导致看书极其不方便，二来系统学习需要花比较长的时间。对于目前这个越来越快餐化的时代来说，的确有很多不适合的地方，不过可以作为初学者的参考书。现在我以一块K3 CPU的代价把它借给了别人，希望我那位同事能够从中得到一些益处。
如果已经具备了C基础，我建议看国内的书，例如钱能的《 C++大学教程（第二版） 》。(如果没有C的基础还是看谭浩强的C语言)。这本书对C讲得还算比较清晰，有很多习题值得一做，特别是最后的struct和union两个部分。其中的一些算法比较拖沓和繁琐（比如树和链表的遍历算法），读者可以尝试修改这些例子，作为最后对C语言的一些总结测试。

梦魇：这个问题让我想起四五年前的情形。今天对于C++有一点认识的人，多半是从那几年就开始学C++了。那时根本没有品牌观念。从书店里找一本C++书，如果看着还算明白，就买下来。我记得那时候宛延闿、张国锋、麦中凡教授的书都受到很高的赞誉。我个人最早的一本C++书是Greg Perry的一本书，今天想起来，其实是一本打着C++旗号的C语言教程。对我作用最大的一本书是国防科技出版社出版的一本书，书名记不得了，作者叫斯蒂芬·布莱哈。
透明：还记得以前曾批评过一本C++书，是北航出的，整本书就没有出现过class关键字。那本书，说穿了其实只是介绍了C语言和iostream库的用法，根本不能算C++。而当时我常常推荐的一本书是电子科技大学张松梅老师的C++教程。那本书，直到今天来看也没有太大的问题，唯一的缺憾就是由于年代久远，许多东西已经过时了。而对于一本技术书籍来说，“过时”是最不可接受的。
总体来说，那时使用C++的人真是在“盲人摸象”。不过这也有好处，就是对C++的很多细节能搞清楚，以后看到经典好书时比较容易理解；当然坏处就是概念不清，甚至都不知道C++和Visual C++、Borland C++到底有什么不一样。

梦魇：整个90年代，其实大部分人对于C++的认识都似是而非。一开始是等同于Borland C++，后来是等同于Visual C++和MFC。所以一般来说，打着BC和VC旗号的书卖得很好，人们觉得这就是C++。而我比较幸运，布莱哈的那本书虽然从现在的眼光来看谈不上高超，但基本路子是对的。可能是因为原书是给UNIX程序员的培训教材，所以没有让我一开始就形成“C++ == VC++”的认识。
其实一直到1996年，我们那里搞计算机的都是唯Borland C++马首是瞻的，到了VC 4.0出来，一下子格局全变了。1997年VC5推出之后，书店里MFC书铺天盖地，学MFC的人，头抬得都比别人高一些。不过现在看来，那时候大部分的MFC书都是三流货色。我曾经有一段时间认为，那一批程序员中间有不少被误导了。根本原因就是相对的封闭。

透明：我觉得一本书的价值有两方面：第一，教给你实用的技术；第二，促使你去思考。对于一本介绍VC（或者说MFC）使用方法的书，我根本不希望它能促使我有什么思考，所以我就一定要求它在技术上精益求精完美无瑕。我刚开始用VC的时候，买的第一本书就是潘爱民老师翻译的《VC技术内幕》（第四版），没有受到那些“三流货色”的误导，应该说是很幸运的。

梦魇：1999年机械工业出版社开始出版“计算机科学丛书”，其中的《Thinking in C++》第一版受到了广泛的欢迎。其实我一直不认为这本书很出色，虽然拿过一次大奖。然而我们都得承认，这本书在C++书籍领域里第一次建立了品牌观念，很多初学者开始知道，不是随便买哪一本都一样的。再往后就是2000年的《 深入浅出MFC（第二版） 》第二版，以及侯先生在《程序员》上发表的那一篇《C++/OOP大系》，加上整个大环境的变化，品牌观念深入人心，C++书籍市场终于开始逐渐与世界同步。
回想往事，我的感觉是，那个需要战战兢兢选择入门书的时代已经过去，今天的C++初学者，大可以放心地买口碑好、自己读起来思路顺畅的书，入门不再是太大的问题。还有一些程序员已经学了几年C++，但看到今天出版的一些新书，感觉比较陌生，这也不是什么问题。侯先生经常说“凡走过必留下足迹”，所谓“走弯路”，未必不是一件好事。
至于具体的推荐表，就不好一概而论了。总之在我的印象里，《Essential C++》、《C++ Primer》、钱能教授的C++教程，都不错。甚至有人一上来就看Bjarne Stroustrup的《The C++ Programming Language》，只要他喜欢，也没什么不可以。

透明：我同意你的观点。不管怎么说，编程是门实践性非常强的学问。要想对C++对象模型有深入的了解，最好的办法就是写一串程序去看结果；要想学会OOP，也只能从项目中学。对于初学者，最好的学习方法就是不停地写程序，写真正有用的程序，写到有问题的时候就去查书，于是自然就会知道哪本书好哪本书不好。不过我们的教育制度能不能让大学里的学生们有这样的学习机会，我表示怀疑。
以我的经验，学C++有两个门槛：入门和使用。完全看不懂C++，这是一个门槛，但是只要有一本合适的入门书，很快就能跨过。要想真正用上C++，却不是件很容易的事情。尤其对于学生来说，接触到的东西多是“玩具”，很难有实战的机会。所以经常看见有人问“C++到底能做什么”，这是C++学习中一个比较麻烦的问题。我们都是做了相当长时间的C++程序之后才看到一些真正经典的书，也正是因为走了相当长的弯路之后才知道这些书的经典之所在。所谓弯路，我想也是一种必须的积累。就算一开始就看《Essential C++》和《C++ Primer》，没有两三年的时间恐怕还是难有所得。

恶魔：有两句十分有道理的话，一是我大学的C语言老师说的“写程序不如说是抄程序”，另一句是一网友说的“好的设计来自借鉴，天才的设计来自剽窃”。对于我这个理性批判主义者来说，这两句话的确不太适合。但是无论从哪个角度来讲，对于初学者来说，剽窃大师的作品是通向成功的最快捷径。
我个人认为，对于C++的初学者来说，首先要确定自己专业领域内主要使用的特性的方向。因为C++的特性如此众多，初学者想贪多基本是不可能成功的。C++的编程范式基本可以分为ADT+PP、GP和OO三个方向。对于ADT+PP范式来说，初学者的主要问题不是学习C++，而是学习C的使用。对于这样的初学者，国内的几本书还是写得比较清楚，符合中国人的习惯，比如谭浩强的《C语言教程》、钱能的《C++语言大学教程》。这两本书我首推第一本，因为这一本我潜心研究了一年，这本书当中很多程序是可以剽窃的，而且可以对这些程序进行加工和提升。比如结构这一章中，它所给出的用struct来实现链表、二叉树的算法是相当蹩脚的。学习ADT+PP的初学者将这本书揣摩透以后可以尝试修改这两个程序。另外这本书的第二版稍微涉及了一些关于“类”的内容。学习ADT+PP的初学者，可以不被OO中的一些专有特性扰乱自己的思路，对于类层次扁平、无继承、无多态的程序编写是有很大好处的。

透明：你好象比较推崇国内教授写的书。现在社会上有种不好的风气：一捧就捧上天，一贬就贬下地。就好象对待谭教授的书，前几年是奉为经典，这几年又有很多人使劲批评。学C++更是有点“崇洋媚外”，总是觉得初学就应该看《Essential C++》。我看这种观点也是片面的。

恶魔：当然《Essential C++》也值得看看。但是我个人觉得这本书没有谭浩强的《C语言教程》来得好。主要原因是：第一，C++的所有特性都点到了，但是不深，看了以后会三心二意没有方向；第二，可以抄袭借鉴的例子太少。《C语言教程》中有很多有趣的问题，比如猴子吃桃、汉诺塔等等，这些例子对于刚刚涉及C/C++语言编程的人来说是学习编程很好的例子。《Essential C++》只能是前两本书看透以后，作为学习C++特性的一个过渡性的书籍。让读者真正领略到什么是C++的编程、和C编程的不同点在哪里。

透明：我发现一个很有趣的现象：初学者往往喜欢问“哪本书比较好”，这让我很是不解。这有点像一个刚学打篮球的人问“王治郅和科比谁比较厉害”。当然科比更厉害一些。但如果你是想学打篮球，这两个人都非常非常有资格教你，你跟谁学都能学得很强——关键不是在于你选哪个老师，而是在于你自己用多少功夫去学。

透明：回到原来话题。学会了C++的语法，能看懂C++代码之后，必须有些书来指导进阶（或者叫指点迷津）。我觉得《设计模式》很好，能够让读者看到一些精妙的用法。不过正如我经常说的，模式带来的麻烦和好处一样多，甚至麻烦还要更多。而且，C++本身的问题使得在C++中使用GoF模式愈加麻烦。

梦魇：《Design Patterns》这本书绝对是不可以没有的，而且中英文版都不可少。最初我看中文版，说实话看不懂，但是也不觉得人家翻译得不好，所以就想，大概是原文就很难懂，加上自己水平有限。于是总是想着再找几本patterns的书来看。后来找到几本书，口碑还不错，不过水平高下，一比就出来了，还是那本《Design Patterns》最经典，最耐看。英文版出来之后，两个版本对照看，明白多了。现在觉得，其实就设计模式来讲，把这本看明白了就很不错了，不用再花费很多心思找其他的书。我现在的包里始终夹着这本书，随身携带，有备无患。
至于说设计模式的副作用，和可能带来的弊端，我的体会也挺多。不过是这样，我们想一想，究竟什么情况下设计模式可以用得很好呢？一种是有经验丰富的人引导，比如要是Robert Martin带队，你在某个地方用错了设计模式，他就会指出来，说这里不对，将来会产生什么样的弊端。对于他来说，丰富的实践经验足以支持他进行“预测型”设计。但是大部分人没这个能力，因此我们只好走第二条路和第三条路，就是“试探型”设计和“重构型”设计。遇到一个问题，你觉得用某种模式挺合适的，就大胆地用了，成功是积累经验，发现不好，出了问题了，只好改回来，那也是积累教训。这叫做“试探型”。至于重构，应该算是最有组织、成功率最高的工程化方法。先把问题“quick and dirty”地解决了，所有的暗礁都暴露出来，然后再根据实际情况采用合适的模式优化设计。现在XP和UP都高度重视refactory，UP在Elaboration和Construction阶段都鼓励抽出专门的iterations进行重构。所以说如果组织快速的软件开发，当然比较倾向于这条路——打成功率嘛。

透明：讲到重构，我顺便说说《Refactoring》这本书的影响。从工程本身的角度来说，你所谓的“重构型设计”是没有什么问题的。但中国的开发者（也包括我在内）往往比较冲动，比较容易相信银弹的存在。曾经有那么一段时间，我在Java中尝试过了重构的方法之后，又拿到C++中去尝试。结果发现，在Java中速度非常快的重构过程，到C++中就被减慢了。究其原因，就是因为C++和Java的约束条件不同。拿着Java中成功的案例直接套C++，不失败才怪。
所以，我必须说：《Refactoring》这本书很有价值。但对于C++程序员来说，它的价值是让你思考，思考这种方法的可行性。如果一个C++程序员没有打算迁移到Java，那么我必须告诉他：《Refactoring》这本书不是让你照着它用的，甚至不是让你去相信它的。对于C++程序员，《Refactoring》全书可以放心相信的只有第13章，其他的部分，都必须非常谨慎地对待。

梦魇：我还要就“试探型”的方法多说两句，我觉得对于个人发展来讲，“试探”也是必不可少的，撞墙不可怕，高水平的人不都是撞出来的吗？你失败了一次，就知道这个模式有什么潜在的问题，下次再用，就会多看几步，像下棋似的。撞的多了，路数就出来了。
我不知道你们是否有这个感觉：用错了模式，吃了亏，再回过头去翻翻《Design Patterns》，看到人家早就指出来这个问题，不过就是那么几句话，原来看上去干巴巴的，现在觉得句句都讲到心坎上，GoF的形象马上就高大起来，还带着光环，感觉是既兴奋又懊悔。

透明：现在回头来看，我更欣赏myan推荐给我的《Designing Object-Oriented C++ Applications Using Booch Method》。这本书能够帮助C++程序员理清思路培养习惯，可惜国内没有引进。相比后来商业味浓厚的UML系列书籍，我觉得这本书对于面向对象的阐释精辟独到，至今未有能出其右者。

梦魇：刚才我们两人都说到Robert Martin，他可是我的榜样。那本1995年的《Designing Object Oriented C++ Application》，我觉得是每一个C++软件工程师都应该反复研读的书。可惜不仅国内没有引进，在国外的名气也不大。如果你觉得面向对象的那些道理你好像都明白，可就是一遇到实际问题就使不上劲，那这本书就是你的最佳导师。
提到理清思路，还有一本书不得不提，就是Andrew Koenig的《Ruminations On C++》。每个人都应该问自己，我学了这么多年的C++，究竟什么是C++最基本的设计理念？遇到问题我第一个直觉是什么？第一个试探型的解决方案应该具有那些特点？如果你不能给出明确的答案，就应该认真地去读这本书，读完了你就有了“主心骨”。

透明：插一句话，谈谈“推荐书”的问题。入门书基本上是放之四海而皆准的，所以推荐的意义也不大。而入门后的发展方向，每个人不同，这个时候就需要“高人”的指点。举个例子：我学C++的时候，myan还不认识我，所以也没有给我推荐书，我还是学过来了，所以即使你当时向我推荐了《Essential C++》或者《C++ Primer》，我也不会太感谢你；但在我认真研究OO的时候，你推荐Robert Martin那本书给我，对我帮助就特别大，而且我从别的地方也很难找到类似的推荐，所以我就很感谢你。
一个程序员，必须有framework的意识，要学会用framework，还要主动去分析framework（在这方面，《Design Patterns》能有一定的帮助）。但是，真正高质量、成气候的framework的书恐怕也就只有针对MFC的。从这个角度来说，MFC纵有千般不是，C++程序员都非常有必要先去用它、熟悉它、研究它，甚至借助《深入浅出MFC》这样的书来剖析它。不然，很难有framework的意识和感觉。
当然，另一个framework也很好，那就是STL。不管用不用MFC、STL，对这两个东西的掌握和理解都是极有帮助的。最近我又在看《深入浅出MFC》，虽然已经不用MFC编程了，但帮助是一定有的。

梦魇：MFC和STL方面，我还是比较推崇侯先生的两本书《深入浅出MFC》和《STL源码解析》。
《深入浅出MFC》这本书，名气自然是大得不得了，不过也有不少人批评。其实书也没有十全十美的，批评当然是少不了的，不过有的时候我看到有人评论这本书，把它跟Inside VC相比，真的是牛头不对马嘴。
你刚才其实说得很对，程序员应该有一点framework意识。而这本《深入浅出MFC》与其说是在讲MFC编程，不如说通篇是在拿MFC为例分析Application Framework的架构和脉络。所以无论你对于MFC本身是什么态度，这本书对每一个C++程序员都有很大的益处。

透明：是的。《VC技术内幕》会告诉你“DYNAMIC_CREATE这个宏怎么用”，《深入浅出MFC》则告诉你“DYNAMIC_CREATE这个宏是怎么实现的”。所以，如果你只需要在VC下写一些小应用程序，《深入浅出MFC》的价值并不太大；但是，如果你需要设计一个稍微大一点的东西（不一定是framework），MFC的设计思想就会有所帮助。

梦魇：另外，我觉得对于MFC也应该有一个公允的评价。过去是吹捧得天上有地下无，书店里铺天盖地都是MFC的书，搞得大家只知有MFC，不知有C++，甚至直到现在还有人问：“我是学MFC呢，还是学C++？VC++是不是比C++更高级的语言？”MFC成了一尊神像，阻碍了人们的视线。所以得把它从神坛上拉下来。这就是过去一两年有很多人，包括我在内批评MFC的一个目的。可是现在大家视野开阔了，.NET也出来了，MFC不再是神像了，少数人就开始以贬损MFC为乐了。我觉得这种态度是不对的。
什么叫好的框架？我觉得在十几年的时间能够象MFC这样保持稳定并且不断进步的框架就是好的框架。可能我们在一些具体的设计问题上有不同看法，觉得“这个地方这么设计不是更漂亮吗？”很多时候是的，但是这不重要，重要的是MFC成熟稳定、有十几年的成功经验，这是最了不起的东西。
另外一点，MFC中间包括着学习Win32 API编程的最佳资料。这是除了其framework方面之外的另一个亮点。我现在使用Win32 API开发，但是经常参考MFC的源代码，收获很大。

透明：STL方面，我对于剖析它的源代码兴趣并不大，毕竟里面源代码多是算法问题。所以，《STL源码剖析》我也只是随便翻翻就束之高阁了。我觉得这本书用来做计算机系的数据结构和算法教材不错，不知道有没有老师乐意这样做。
对于STL，我的态度一向都是“应用至上”。不过，我一直认为SGI STL本身就是一本精彩的书，一本数据结构和算法的经典参考书，同时也是泛型技术的参考书。想知道一个算法是如何实现的，看看STL源代码就行；想知道如何使用type traits，STL源代码里面也有例子。看别人写的书，总觉得隔着一层纱，有点挠不到痒处的感觉。SGI STL的代码写得非常漂亮，一个C++程序员如果不看看这本书，实在是可惜。

梦魇：至于STL，除了《STL源码解析》之外，我举贤不避亲，强烈推荐侯先生与我合译的那本《The C++ Standard Library》。这本书质量之高是无需怀疑的。我现在手边常备此书，随时查阅，对我帮助很大。

透明：C++和Java相比，最大的优势就是它没有一个专门的公司来管它，最大的弱点也是它没有一个专门的公司来管它。Java程序员在学会简单的语法之后，立刻进入SUN提供的framework，一边用这个现成的framework做实际开发，一边在开发过程中继续学习Java一些幽深的特性。而这个时候，C++程序员恐怕还在问“VC和BCB哪个好”呢。这无疑是浪费时间。

梦魇：刚才你说Java和C++的优劣，这个话题已经成了我们这个年代永不消失的声波了。我也不想再谈这个。不过有一点我得说清楚：现在我们很多用C++的人吃了不少苦头，探过脖子去看看Java，觉得它真是太可爱了，这种印象是不准确的。另外，Java也不简单，而且会越来越庞大复杂。在很多场合，Java还不具有竞争力。至于将来如何，我看有些Java爱好者也过分乐观了，似乎计算机科学界几十年解决不了的问题都可以借着Java的东风解决掉，恐怕没那么容易。

透明：那当然。我再次强调：No Silver Bullet。读书很重要，但古人说“行万里路，读万卷书”，还是把“行路”放在“读书”前面。尤其对于技术书籍，如果它不能帮我解决问题、不能给我带来非常实际的利益，那么我是不会去读它的。恶魔说得对，我们这个社会很快餐，我们这个行业尤其很快餐，我们也只能努力适应它。

❼ 什么是专业的程序员

看了孟岩的文章 《程序员必须走向专业化》 ，有点感想。 真正专业的软件工程师, 企业宁要专业的工程师，不要不专业的牛人。专业性保证了一个程序员的技能和工作能够为组织带来效益，而他们只会为这种效益付酬，不会出于对大牛的敬仰之情而主动上缴贡银。而且，他们也相信，只要一个人专业化程度足够，技术和经验上的不足是容易在实践中弥补的。 记得近两年有一句很流行：老大, 咱没这么干过，咱不专业啊 专业的企业精神 （做事高效负责，规范化的价值观和知识体系，规范化的工作习惯和职业纪律，职业化的工作作风和流程）2.编程很专业（技术精湛，经验丰富，有独立分析问题和解决问题的能力）3.做事很专业（善于沟通，不论是和客户、同事、项目经理、新手，还是老手，乐于和他人合作，具有团队精神） 与之相对应的就是不专业的程序员：1.无企业精神（个人主义严重，觉得自己技术特牛，贡献特大，认为企业给的薪水少，干活不该卖力，项目经理安排的任务故意拖拉不服从，上班很晚到等）2.编程不专业（没写过几行代码，没做过什么大系统，就认为自己技术特精湛，其实写的代码却不堪一击；没工作几年就认为经验特丰富，没碰到过多少客户和生产上的具体问题就认为有丰富的分析问题和解决问题的能力）3.做事不专业（难于沟通和合作，没有团队精神和集体精神，不是本着解决问题的态度和学习提高的态度，而是本着耍弄技巧、高人一等甚至刁难别人的态度，和客户没沟通点、和项目经理沟通阴奉阳违，对新手好为人师，对老手不屑一顾等等） 几乎每个团队都有几个专业的程序员，即主程序员，也有很多不专业或即将专业的程序员；有刚毕业朝气蓬勃的白纸小伙，也有业务经验丰富但默默无闻的老黄牛，有满身带刺的所谓技术牛人，也有不大伸张的真正牛人；项目经理如何管理和激励团队成员，扬长避短，使团队发挥最大战斗力，如何帮助团队成员成长，这是项目经理需要思考的问题。 而从程序员自身来说，则应当向专业化的方向努力，无论你的职业方向是管理、技术、还是技术管理，这些都是必须的。因为说到底，只有你做的专业，只有你做出来的东西专业，才能让人信服。附：很多人谈到职业素养问题，《程序员》杂志 刊登的程序员职业素养：1. 学习和分析能力 。每个团队都在成长，作为程序员这个群体就更需要与时俱进。尤其是在开发这个知识日新月异的行业里，同时分析能力是必不可少的。像本案例中，如果没有在充分了解客户需求的基础上的精准分析，很难想象最后的结果。；（调查中71.15%人认为，学习能力是程序员基本能力中比较重要的一条。另外，此次调查中57.69%的被访者认为，在技术方面有不同意见时，处理妥当的程序员必要的修炼之一。相信这个案例为我们提供了新的思路。2. 与内外保持良好沟通，永远是成功的保证 。及时汇报、沟通进展也可以在第一时间发现自己的偏差。在改bug问题上，有些小bug ，程序员可能比较容易就修改了，但有些比较难修改的bug ，如果自己解决不了，应该像同事或者专家请教，甚至组织小组讨论，但有些程序员处理这种情况时，往往是自己琢磨半天，改不了，然后就放那去做别的事情了，等过几天项目经理问起来时，才承认自己改不了，这种现象应该最大程度地避免。毕竟，相差一度两条线顶点的距离会在不限延伸后相差不限大。（59.62%的被访者认为汇报项目进展时明确及时是程序员内在修炼的重要组成）3.产品意识 。良好的产品意识可以大幅度提高开发效率。某次产品改版中界面都重新修改过了，因为有2个程序员专门负责编程匹配部分，而其中一个就非常具有产品意识，他用 .NET把UI原形都画了出来，在公司内部组织讨论，让最后的客户环境和界面都非常优秀。4.团队意识 。作为一个新人要向老人请教学习，作为一个老人要把自己的心得、收获、技能等与新人分享，也就是要带新人。知识的分享是知识学习中一个最有效的方法，尤其是在程序员这个行当里；5. 对于编码规范和文档规划是毫无疑问必须要遵守的 。（此次参加调查的程序员中有80.77%认为编码规范是程序员内在修炼的毕选项。、68.59%认为文档规范是修炼的必要内容。）

❽ 请大家帮我开解一下

作为一个程序员，要学好编程，先学好学精c语言，c语言博大精深。学好c语言能够深入理解程序深层次的东西。
到了商业领域，企业为了软件开发效率和节约成本，所以用java。而且java那么多API，集成度高，不学c语言而直接去学java，会造成知其然而不知其所以然。我个人认为java等一些高级语言会堕化人的编程能力。

❾ 编程之美的作品评价

（1）的确是好书，不同于算法导论和程序设计艺术之类的书（比较抽象），结合很多比较现实易于形象化的题目，大开眼界。每天做两道题目，感觉挺有收获的。
——互动网读者superzxt
（2）这本书对于学生求职还是很有帮助的，通过做题可以先感受一下笔试面试气氛，拓宽自己的解题思路，从而有助于找到一份不错的工作。强烈推荐大家对每一道题目都好好揣摩揣摩，必能受益良多。
——互动网读者cx_flying
（3）这本书表面上是讲解算法，实际上体现了一种面对困难、解决问题的心态……个人还是挺喜欢这类书的，把编程人性化了……
——互动网读者拓荒者
（4）……这本书更大的作用在于——给你一个有趣的题目，让你自己去思考，思考出来后再对照它给出的解法，看看你是否做对了。在这个过程中，你学会了作为一个程序员最重要的东西——独立思考的能力，而不是碰到问题就在网上到处找代码片段，盲目拷贝已有的解决方案。
——互动网读者CoolJie2001
（5）买这本书是因为看到这本书名字的前四个字，而非后面几个字。看着书的封面，朴素简单的设计，处处透出清新之美。
随着软件产业的迅速发展，各种高级编程语言铺天盖地席卷而来，软件开发变得单调而枯燥，而编程本身的乐趣如今却很难在身边找到。这本书正是迎合了我的想法，编程本身应该非常有乐趣，通过巧妙的思考，寻求解决问题的方法。《编程之美》放在案前，每有倦意，品杯香茶，翻开几页，感受久违的古色古香，沉浸在美妙的思考中，别有一翻滋味~~
——当当网读者nuaapjy
（6）之前对算法的印象是晦涩难懂，每每总是望而却步，提不起来兴趣去研究算法，读了《编程之美》中的几个算法，有一种豁然开朗的感觉，原来算法也可以讲的这么生动有趣，这么吸引人。《编程之美》中的算法以实例开题，循序渐进的解决问题，一步步去剖析算法的本质，挖掘和发散算法功效，进而去淋漓尽致的体现算法的美妙！
——当当网读者萝卜萝卜闪金光
（7）一本编程的课外读物，引发编程兴趣的好书。
——当当网读者tiangu0120
（8）此书重要的是开拓思路，有一定基础的朋友看了这个，就会有一种意犹未尽的感觉，“原来还可以这么玩啊”的想法。
——卓越网读者yc_andy1009
（9）刚刚读完这本书，感觉不错，启发很大，这是我继读完《算法导论》以来发现比较好的一本书，推荐对算法以及对大公司的面试题有兴趣的人去看看。
——卓越网读者lironghua
（10）算法是计算机程序设计的灵魂，是每个计算机专业的学生和从业人员必须具备的基本素质之一。微软把一些看似简单，实则蕴含深刻内涵的算法题目作为面试的重要内容，是经过深思熟虑了的。
——网友Sswv
（11）《编程之美》中这些谜题考察、锻炼的是扎实、严密和具有创造性的思考能力，面对问题有条不紊的分析能力，和不断深入、刨根问底的精神。毫无疑问，这些素质，都是软件工程师身上最宝贵的东西。
——《程序员》杂志技术主编孟岩
（12）随着软件产业的迅速发展，各种高级编程语言铺天盖地席卷而来，软件开发变得单调而枯燥，而编程本身的乐趣如今却很难在身边找到。《编程之美》正是迎合了我的想法，编程本身应该非常有乐趣，通过巧妙的思考，寻求解决问题的方法。
——当当网读者nuaapjy
（13）我招人的时候找了《编程之美》上面的题目作参考，效果还不错。里面描述的算法很有意思。
——当当网读者beikerray119
（14）工程师的骄傲，在于创造。编程的乐趣也在于探索。当我们不仅爱玩电脑，会玩电脑，也尝试着用电脑去解决实际的问题并获得成功的时候，那种自我肯定的快乐是一般途径所体会不到的。
何为编程之美？巧妙的思路，简明的算法，严谨的数学分析——这些综合起来就是编程之美。
——网友Ultra

❿ 推荐学习c++ stl 使用方法的书籍

C++标准程序库:自修教程与参考手册
Nicolai M.Josuttis (作者), 侯捷 (译者), 孟岩 (译者)

这是一本非常好的书，因为它的知识是非常详细的，作者的思想非常好，全书没有一点空话、废话，每一点知识都可以让我们思考学习。是站在读者的角度写的这本书。
此书是学习C++标准程序库的必读教材。

如果你初学C++，不要选择这本书。
应该先读一下primer或者The c++ programming language

如果你对C++有了一定的理解，对面向对象变成有基本的掌握。或者试着自己实现过string，vector等容器，那么读这本书将对你大有裨益。

如果你是高级程序员，那么这本书无疑可以成为你STL参考书的首选。