学习C++：实践者的方法（Beta1）

学习C++：实践者的方法（Beta1）

By 刘未鹏(pongba)

C++的罗浮宫(http://blog.csdn.net/pongba)

（注：该文处于Beta阶段，等待反馈中，请勿转载）

前言

我的blog以前很长一段时间关注的都是C++中的技术&细节，乃至于读者和应者都寥寥。然而5月份的时候写的一篇“你应当如何学习C++”，阅读量却达到了3万多，在blog上所有文章中却是最高的（且远远超过了第二位）；评论数目也有一百多。为什么独独这篇能够激起这么多的回应，想必是国内的C++社群被C++压抑太久，或者，严格来说，是被C++的教育方式压抑太久。实际上，不管是在各大国内论坛上，还是在comp.lang.c++.moderated这样的国际C++论坛上，乃至于在douban上的小组内，有心者都会发现，对C++语言的细节的关注一直都没有停止过，同样，对C++语言的细节的抱怨也从来都没有停止过。一个例子就是comp.lang.c++.moderated上的一个技术牛人James Kanze说的，他说接触C++十年了，到现在还需要不时去翻C++标准。这就难怪Eric Raymond老大在《The Art of Unix Programming》中说“C++是反紧凑”的了。C++中的细节太多，就算都看过了，也不可能都记住。更关键的是，就算都记住了，也不能让你成为一个真正的好程序员。

绝大多数人都把细节太多（或者用贬义词来说就是“阴暗角落太多”）归结为C++的本质问题，认为一切邪恶由此而生。也正因此，大约9月份的时候，Linus在邮件列表上说“C++是一门有思想包袱的语言；仅仅是为了让程序员远离C++，我也要用C”。这句短短的话在国内引起了很大的反应，最初是刘江转了Linus的话，然后云风和孟岩都发表了自己的看法；我也写了一篇“Why C++”（后来发给Bjarne，Bjarne对这篇文章做了一个友情评注）。

然而，这一通浑水搅过之后，我相信引起的变化未必很大。大多数原先的反对者能从中找出反对的理由，于是更加反对；大多数原先的赞同者也能从中找到赞同的理由，于是更加赞同；而剩下来的原先没有明确意见的，看双方各有各的道理，可能还是没有头绪。

摆脱自我服务偏见——理性思考的前提

《决策与判断》上提到过一个有趣的真实故事：1980年的某一天，美国空战司令部的计算机突然发出警报——苏联的一枚核弹正在向美国本土飞来。司令部立即调兵遣将，迅速为一场核战做好了准备，然而3分钟之后，工程人员发现是计算机的一个小零部件故障造成的。然而，这场虚惊之后，大众的反应才是真正有意思的：原先支持核武装的，认为现在感觉更加安全了（因为“事实证明这类的故障是完全可克服的”）；而原先反对核武装的则认为更不安全了（因为“这类错误信号可能导致苏联过度反应，引发真正的核战”）。类似的情况也发生在三里岛核泄露事件之后，同样的，反对者认为（“这表明管理部门没有办法安全管理核能”），支持者认为（“这正表明这样的危险没有想像得那么严重，是可克服的”）。社会心理学把诸如此类的现象总结为“自我服务偏见”。不幸的是，“真理越辩越明”其实只适用于理性思考者。

为什么啰嗦这么一大通呢？就是因为，一直以来泛滥于程序员社群的“语言之争”，背后真正的原因其实并不在于语言实质上的优劣，而在于观察者的眼睛。在观察者的眼睛里面，语言并非一门工具，而是自己花了N多时间（其中尤数C++为最）来“修炼”的技能，对于这样的技能，被否定无疑等同于自己被否定。所以，从心理学上讲，语言并不是工具（尽管一直有这么一种呼吁），而是信仰。这样的信仰在越是花得时间久的语言上越是激烈。有趣的是，几乎所有的“热闹”的社群都有这样的现象，Java、Python、Ruby…莫不如是；因为就算语言本身不复杂，程序员仍然还是要投入大量的精力去学习各种各样的框架类库（想想Java的那些框架？）。因此这些语言社区的信仰未必不比C++社群的强烈。

然而，一旦弄清我们为什么会把语言当成信仰，就非常有助于摆脱在看待语言时的“自我服务偏见”，从客观的角度去看待问题。——“当你看到的是支持某个意见的证据时，试着去想一想有哪些证据是不支持它的”。

那么为什么要摆脱自我服务偏见？说小了，是为了成为一个更优秀的程序员（谁也不希望因为偏见而去使用一门低效的语言乃至不妥当的语言）。说大了是节省生命（因为偏见可能导致越陷越深，浪费时间）。

所以，如果你能够理性的思考我们将要讨论的问题，避免自我服务偏见（就当你从来没有花时间在C++上一样）。那么我们便可以开始讨论真正的问题了。

前言2

现在，几乎每个学习C++的都知道C++的核心问题是其复杂性；甚至本身不在C++社群的，也知道这是事实。群众的眼睛是雪亮的，何况这还是个太显而易见的事实。

但看了无数篇阐述C++复杂性的文章，和争论C++复杂性的吐沫星子（包括我前段时间写的两篇关于C++的总结）。我始终都有一个感觉——没分析透，就跟盲人摸象一样。正如“Why C++”的一位读者批评的，我在文章里面没有写明到底哪些是C++的“非本质复杂性”。当然，我自己凭感觉就能知道，而接触C++一段时间的人大致也能知道，但新手乃至非新手则对我所谓的“非本质复杂性”根本没有一个具体的认识，这就使得那篇“Why C++”脱离了原本的意图——面向所有C++使用者和学习者。

同样的原因，在写了“你应当如何学习C++”一文之后，当孟岩先生邀请我给《程序员》写一个系列的文章，介绍一下我在接触C++的过程中的态度和认识转变时，我虽然非常高兴的答应了，但直到现在3个月过去了还是颗粒无收。为什么？因为我觉得真正本质的问题没有被清晰的触摸到；所以直到现在我都没有动笔，免得废话说了一大堆，除了能被当成小说读读之外，对真正考虑是否要学习乃至使用C++的人未必有什么实际用处。

然而，这么个念头一直都放在潜意识里面。前一阵子和Bjarne通信，谈到了关于C++复杂性的一些想法，在邮件里面总结了一下C++的复杂性来源，感觉思路清晰了许多。而这篇文章要达到的目的，正是传达对C++的复杂性的一个具体而明确的认识，有了这个认识作为支持，我们便可以推导出学习C++的最佳（实践者）的方法。

为什么要学习（并使用）C++

显然，如果找不出要学习C++的理由，那么谈什么“正确的学习方法”等于是废话。

首先重复一句Bjarne的话：“我们的系统已经是极度复杂的了，为了避开C++的复杂性而干脆不用C++（Linus的做法），无异于因噎废食。”在所有可用C和C++的领域，C++都是比C更好的语言。当我说“更好的”时候，我说的是C++拥有比C更安全的类型检查、更好的抽象机制、更优秀的库。当然，凡事都有例外，如果你做的项目1）不大。2）编码中用不到什么抽象机制，甚至ADT（抽象数据类型，例如std::complex这种不含多态和继承的）也用不到，RAII也用不到，异常也用不到。3）你连基础库（如，简化资源管理的智能指针、智能容器）都用不着。那么也许你用C的确没问题；所以如果你的情况如此，不用和我争论，因为我无法反驳你。我们这里说的领域大致是Bjarne在“C++应用列表”里面列出来的那些地方。

底线是：如果把C++中的诸多不必要的复杂性去掉，留下那些本质的，重要的语言特性，简化语言模型，消除历史包袱。即便是C++的反对者也许也很难找到理由说“我还是不用C++”。在我看来，一个真正从实践意义上理性反对使用C++的人只有一个理由：C++的复杂性带来的混乱抵消乃至超过了C++的抽象机制和库（在他的特定项目中）带来的好处。

值得注意的是，这里需要避免一个陷阱，就是一旦人们认定了“C++不好”，那么这个理由就会“长出自己的脚来”，即，就算我们拿掉C++的复杂性，他们可能也会坚持还是不用C++，并为之找一堆理由。我假定你不是这样的人。不过，也许最可能的是他会说：“问题是我们今天用的C++并非如此（简洁），你的假设不成立。”是的，我的假设不成立。但虽然我们无法消除复杂性，我们实际上是可以容易地避开复杂性，避短扬长的。这也是本文的要点，容我后面再详述。

当然，到现在你可能还是会说。我还是不用C++，因为我可以用D；或者如果你本来做的项目就不需要C++，你则可能会说，我用Python。首先，如果你的项目能用Java/Python乃至Ruby做，那么用C++是自讨苦吃。因为能用那些语言代表你的项目在效率上本身要求就不高，那么用一门效率上讨不到太大好处，复杂性上却绰绰有余的语言，有什么价值呢？其次，如果你的项目效率是很重要的，你可能会说可以用D。然而现实是D在工业界尤其是国内被运用得非常少，几乎没有。而C++却有大量的既有代码，已经使用C++去做他们的产品的公司，在很长一段时间之内几乎是不可能用别的语言重写代码的，正如Joel所说，决定重写一个非平凡的代码基==自杀。所以，我们至少要注意以下两个明显的事实：

事实1：C++在工业界仍有稳定的核心市场。

这个事实大概不需要多加阐述，很多大公司的核心技术还是要靠C++来支撑的（见Bjarne主页上的C++应用列表）。所谓事实，就是未必是大家最愿意承认的情况，但又不得不承认。C++积累了庞大的代码基，这个代码基不是一朝一夕能够推翻的。D从语言角度来说的确优于C++，但最关键的就是还没有深入工业界（也许根本原因是没有钱支持，但这不是我们讨论的重点）。而C呢，根据Bjarne本人的说法，他的观察是主流工业界的趋势一直是“从C到C++”的，而不是反过来，至少在欧美是如此。在国内我们则可以通过CSDN上的招聘情况得到一个大致类似的信息。

事实2：C++程序员往往能享受到有竞争力的薪酬。

是的，这不是一篇不食人间烟火的技术文章。这个事实基于的逻辑很简单：物以稀为贵。Andrei Alexandrescu这次来中国SD2.0大会的时候，在接受采访时也说过：“最赚钱的软件（如MS Office）是C++写的”。孟岩也在blog上提到这么个事实，我想他作为CSDN的技术总编，业界观察肯定比我清晰深刻。所以我这里就不多废话了。

当然，以上逻辑并不就意味着在怂恿你去学C++，一切还要看你的兴趣。所以如果你志不在C++身处的那些应用领域，那这篇文章并非为你而写。

“C++的复杂性是根本原因”——一个有漏洞的推理

一旦我们认识了C++在一些领域是有需求的（值得学习和掌握的）这个问题之后，就可以接下来讨论“怎样正确学习和掌握C++”这个核心问题了。

其实，对于这个问题，Bjarne已经宣传了十年。早在99年的时候Bjarne就写了“Learning C++ as A New Language”，并在好几篇技术访谈（这里，这里，这里，还有这里）里面提到如何正确对待和使用C++中支持的多种抽象机制的问题。Andrew Koenig也写了一本现代C++教程《Accelerated C++》（这本书后面还会提到）。然而这么多年来，C++社群的状况改善了吗？就我所知，就算有改善，也是很小的。学习者还是盲目钻语言细节，只见树木不见森林；网上还是弥漫着各种各样的“技术”文章和不靠谱的“学习C++的XX个建议”；一些业界的有身份的专家还是在一本接一本的出语言孔乙己的书（写一些普通程序员八辈子用不着的技巧和碰不着的角落）；而业界真正使用C++的公司在面试的时候还总是问一些边边角角的细节问题，而不是考察编程的基本素养（不，掌握所有的语言细节也不能让你成为一个合格的程序员）。这个面试理念是错误的，估计其背后的推理应该是“如果这个家伙不知道这个细节，那么估计他对语言也熟悉不到哪儿去；而如果他知道，那么虽然他可能并不是好的程序员，但我们还是能够就后一个问题进一步测试的”，这个理念的问题在于，对语言熟悉到一定程度（什么程度后面会具体建议）就已经可以很好的编程了（剩下的只需查查文档）；而很多公司在测试“对语言熟悉程度”的时候走得明显太远了（比如，问临时对象生命期和析构顺序当然是无可厚非的，但问如何避免一个类被拷贝或者如何避免其构建在堆上？）；当然，有些语言知识是必须要提前掌握的，具体有哪些后面会提到，面试的时候并非不能问语言细节，关键是“问哪些”。

所以说：

事实3：C++的整个生态圈这么些年来在学习C++的哲学上，实在没有多少改善。

为什么？是因为Bjarne介绍的学习方法在技术上没有说到点子上？是Andrew Koenig的书写得不够好？说了谁也不会相信。因为实际上，这里的原因根本不是技术上的，而是非技术的。

众所周知的一个事实是，从最表层讲，C++的最严重问题是在语言学习阶段占用了学习者的太多时间。翻一翻你的C++书架或者电子书目录，绝大多数的C++“经典”都是在讲语言。在我们通常的意义上，要“入门”C++，在语言上需要耗的时间一般要两三年。而要“精通”C++，则搞不好需要耗上十年八年的。（这跟Peter Norvig说的“十年学习编程”其实不是一回事，人家那是说一般意义上的编程技能，不是叫你当语言律师。）

那为什么我说“C++的复杂性是根本原因”是个有漏洞的推理呢？因为，要让人们在使用一门语言去做事情之前耗上大量时间去学习语言中各种复杂性，除了语言本身的复杂性的事实之外，还有一个重要的事实，那就是学习者的态度和（更重要的）方法。而目前大多数C++学习者的态度和方法是什么呢？——在真正用C++之前看上一摞语言书（日常编程八辈子都未必用得到）。而为什么会存在这样的学习态度呢？这就是真正需要解释的问题。实际上，有两方面的原因：

事实4：市面上的绝大多数C++书籍（包括很多被人们广泛称为“必读经典”的）实际上都是反面教材。

也就是说，随便你拿起哪本C++书籍（包括很多被人们广泛称为“必读经典”的），那么有很大的可能这本书中的内容不是你应该学的，而是你不应该学的。我之所以这么说有两个原因，因为一，我曾经是受害者。二，也是更实质性的原因，这些所谓的必读经典，充斥的是介绍C++中的陷阱和对于C++的缺陷的各种workarounds（好听一点叫Idioms（惯用法）或techniques（技术））；又因为C++中的这类陷阱和缺陷实在数不胜数，所以就拉出了一个“长尾”；这类书籍在所有语言中都存在（“C缺陷和陷阱”、“Effective Java”、“Effective C#”等等），然而在C++里面这个尾巴特别长，导致这类书数不胜数。三，这些书中列出来的缺陷和陷阱根本不区分常见程度，对于一个用本程序员来说，应该希望看到“从最常见的问题到最不常见的问题”这样的顺序来罗列内容，然而这些书里面要么全部混在一起，要么按照“资源管理、类设计、泛型”这样的技术分类来介绍内容，这根本毫无帮助（如果我看到一个章节的内容，我当然知道它讲的是类设计还是资源管理，还用废话么？），使得一个学习者无法辨别并将最重要的时间花在最常见的问题之上。

最最关键的是：这些书当中介绍的内容与成为一个好程序员根本毫无关系，它们顶多只能告诉你——嗨，小心跌入这个陷阱。或者告诉你——嗨，你知道当你（八辈子都不一定遇到）遇到这个需求的时候，可以通过这个技巧来得以解决吗？结果读了一本又一本之后，你脑袋里除了塞满了“禁止”、“警戒”、“灯泡”符号之外，真正的编程素质却是一无长进。又或者有这样一类书，热衷于解释语言实现背后的机制，然而语言特性本质上是干嘛用的？是用来在实际编码中进行抽象的（说得好听一点就是“设计”），不是用来告诉你这个特性是怎么支持的。比如我就见过以下的情景：面试官问：“你知道虚函数吗？”得到的回答是一堆关于虚函数表机制的解释。面试官又问：“那虚函数的好处是什么呢？”到底为什么要虚函数呢？得到的回答是：“恩…啊…就是…多态吧”（这时已经觉得回答不够深刻了）。再问：“那多态是干嘛的呢？”哑口无言。

事实5：就算记住一门语言的所有细节也不能让你成为一个合格的程序员。

事实6：了解语言实现固然有其实践意义（在极端场合的hack手法，以及出现底层bug的时候迅速定位问题），然而如果为了了解语言机制而去了解语言机制便脱离了学习语言的本意了。

在C++里面这样的情况很多见：知道了语言实现的底层机制，却不知道语言特性本身的意义在什么地方。本末倒置。为什么？书害的。二，这类书当中介绍的所有情景加起来其实只属于那20%（二八法则），甚至20%都不到的场景（究竟是哪些书，后面会介绍，我不便直接列出书名，打击面太大，但我会把我认为essential的书列出来）。这就是为什么我说“八辈子都用不着”的原因。

事实7：80%的C++书籍（包括一些“经典”）只涉及到20%（或者更少）的场景。

你可能会说，那难道这些书就根本不值得看了吗？

我的回答是，对。根本不值得看。——但是值得放在旁边作为必要的时候的参考（记住从索引或目录翻起，只看严格必要的部分），如果你是个严肃的程序员的话。因为不管承认与否，墨菲法则的强大力量是不可忽视的——如果有一个可能遇到的陷阱，那么总会遇到的。而同样，C++的那些奇技淫巧也并非空穴来风，总有时候会需要用到的。但是你不需要预先把C++的所有细节和技巧存在脑子里才能够去编程，即：

建议1：有辨别力地阅读（包括那些被广泛称为“经典”的）C++书籍。

如果书中介绍的某块内容你认为在日常编程中基本不会用到（属于20%场景），那么也许最好的做法是非常大概的浏览一下，留个印象，而不是顺着这条线深究下去。关于在初学的时候应该读哪些书，后面还会提到。

实际上，除了语言无关的编程修养之外（需要阅读什么书后面会提到），对于C++这门特定的语言，要开始用它来编程，你只需知道一些基础但重要的语言知识（需要阅读哪些书后面会提到）以及“C++里面有许多缺陷和陷阱”的事实，并且——

建议2：养成随时查阅资料和文档的习惯。

“查文档”几乎可以说是作为一个程序员最重要的能力（是的，能力）了；它是如此重要，以至于在英文里面有一个专门的缩写——RTFM。为什么这个能力如此重要，原因很简单：编程领域的知识太鸡零狗碎了。不仅知识量巨大，而且知识的细节性简直是任何学科都无与伦比的（随便找一个框架类库看看它的API文档吧）。所以，把如此巨量的信息预先放在脑子里不仅不实际，而且简直是自作孽。你需要的是“元能力”，也就是查文档的能力——从你手头遇到的问题开始，进行正确合理的分析，预测问题的解决方案可能在什么地方，找到关于后者的资料，阅读理解，运用。

同样，在C++中也是如此，如果你从学习C++一开始就抱着这种态度的话，那么即便等到面试的时候被问到某个语言细节，你也可以胸有成竹的说你虽然并不知道这个细节，但在实际编码中遇到相应问题的时候肯定会找到合适的参考资料并很快解决问题（解决问题，才是最终目的）。当然，更大的可能性是，你在平常编码中已经接触过了最常见的那80%的陷阱和技巧了，由于你用的是实践指导性的学习方式，所以你遇到的需要去学习的陷阱和技巧几乎肯定都是常见场景下的，比没头苍蝇似的逮住一本C++“经典”就“细细研读”的办法要高效N倍，因为在没有实践经验的情况下，你很可能会认为其中的每个技巧，每个陷阱，都是同样概率发作的。

为什么市面上的C++书热衷于那些细节和技巧呢？

你用一个天生用来开啤酒瓶的工具开了啤酒瓶，不但啥成就感也没有，而且谁也不会觉得你牛13。然而，如果你发明了一种用两根筷子也能打开啤酒瓶的办法，或者你干脆生就一口好牙可以把瓶盖啃开，那也许就大不一样了。人家就会觉得你很好很强大。

事实8：每个人都喜欢戴着脚镣跳舞。

也就是说，如果你用一个天生为某个目的的工具来做他该做的事情，没有人会喝彩，你也不会觉得了不起。但如果你用两个本身不是为某个目的的工具组合出新功能的话，你就是“创新”者（尽管也许本来就有某个现成的工具可用）。

而C++则是这些“创新”的土壤，是的，我说的就是无穷无尽的workarounds和惯用法。但问题是，这些“创新”其实根本不是创新，你必须认识到的是，他们都只不过是在没有first-class解决方案的前提下不得已折腾出来的替补方案。是的，它们某种程度上的确可以叫创新，甚至研究可行的解决方案本身也是一件非常有意思的事情，但——

事实9：我知道它们很有趣，但实际上它们只是补丁方案。

是的，不要因为这些“创新”方案有趣就忍不住一头钻进去。你之所以觉得有趣是因为当你一定程度上熟悉了C++之后，C++的所有一切，包括缺陷，对你来说就成了一个“既定事实”，一个背景，一个习以为常的东西（人是有很强的适应性的）。因此，当你发现在这个习以为常的环境下居然出现了新的可能性时，你当然是会欢呼雀跃的（比如我当年读《Modern C++ Design》的时候就有一次从早读到晚，午饭都没吃），然而实际上呢？其它语言中也许早就有first-class的支持了，其它语言也许根本不需要这个惯用法，因为它们就没有这些缺陷。此外，从实践的角度来说，更重要的是，这些“解决方案”也许你平时编程根本就用不到。

不，我当然不是说这些补丁方案不重要。正如前面所说，C++中繁杂的技巧并非空穴来风，总有实际问题在背后驱动的。但问题是，对于我们日常编程来说，这些“实际问题”简直是八杆子打不着的。犯不着先费上80%的劲儿把20%时候才用到的东西揣在脑子里，用的时候查文档或书就行了。

看到这里，塑造C++中特定的心态哲学的另一个原因想必你也已经知道了。实际上，这个原因才是真正根本的。前面说的一个原因是C++书籍市场（教育）造就的，然而为什么人们喜欢写这些书呢？进一步说，为什么人们喜欢读这些书呢？（我承认，我也曾经读得津津有味。）答案很简单：心理。每个人都喜欢戴着脚镣跳舞（事实8）。认识到这一点不是为了提倡它，而是只有当我们认识到自己为什么会津津有味地去钻研一堆补丁解决方案的时候，我们才真正能够摆脱它们的吸引。

总而言之，C++的复杂性只是一个必要条件，并非问题的根本症结。根本症结在于人的心理，每个人都喜欢戴着脚镣跳舞，并且以为是“创新”。意识到这一点之后可以帮我们避免被各种各样名目繁多的语言细节和技巧占去不必要的时间。

然而，C++的复杂性始终是一个不可回避的现实。C++中有大量的陷阱和缺陷，后者导致了数目惊人的惯用法和workarounds。不加选择的全盘预先学习，是非常糟糕的做法，不仅低效，而且根本没有必要，实在是浪费生命。爱因斯坦曾经说过，“我只想知道‘他’（宇宙）的设计理念，其它的都是细节”。然而，正如另一些读者指出的，如果对C++中的这些细节事先一点都没有概念的话，那么实际编码中一旦遇到恐怕就变成没头苍蝇了，也许到哪里去RTFM都不知道。这也是为什么那么多C++面试都会不厌其烦地问一些有代表性的语言细节的原因。

把细节全盘装在脑子里固然不好，但对细节一无所知同样也不是个办法。那么对于C++程序员来说，在学习中究竟应该以怎样的态度和学习方法来对付C++的复杂性呢？其实答案也非常简单，首先有一些很重要&必须的语言细节&特性是需要掌握的，然后我们只需知道在C++中大抵有哪些地方有复杂性（陷阱、缺陷），那么遇到问题的时候自然能够知道到哪儿去寻找答案了。具体的建议在后文。

C++的复杂性分类

本来这一节是打算做成一个C++复杂性索引的，然而一来C++的复杂性太多，二来网上其实已经有许多资料（比如Bjarne Stroustrup本人的C++ Technical FAQ就是一个很好的文档），加上市面上的大多数C++书里面也不停的讲语言细节；因此实际上我们不是缺乏资料，而是缺乏一种索引这些资料的办法，以及一种掌控这些复杂性的模块化思维方法。

由于以上原因，这里并不详细罗列C++的复杂性，而是提供一个分类标准。

C++的复杂性有两种分类办法，一是分为非本质复杂性和本质复杂性；其中非本质复杂性分为缺陷和陷阱两类。另一种分类办法是按照场景分类：库开发场景下的复杂性和日常编码的复杂性。从从事日常编码的实践者的角度来说，采用后一种分类可以让我们迅速掌握80%场景下的复杂性。

二八法则

以下通过列举一些常见的例子来解释这种分类标准：

80%场景下的复杂性：

1. 资源管理（C++日常复杂性的最主要来源）：深拷贝&浅拷贝；类的四个特殊成员函数；使用STL；RAII惯用法；智能指针等等。

2. 对象生命期：局部&全局对象生存期；临时对象销毁；对象构造&析构顺序等等。

3. 多态

4. 重载决议

5. 异常（除非你不用异常）：栈开解（stack-unwinding）的过程；什么时候抛出异常；在什么抽象层面上抛出异常等等。

6. undefined&unspecified&implementation defined三种行为的区别：i++ + ++i是undefined behavior（未定义行为——即“有问题的，坏的行为，理论上什么事情都可能发生”）；参数的求值顺序是unspecified（未指定的——即“你不能依赖某个特定顺序，但其行为是良好定义的”）；当一个double转换至一个float时，如果double变量的值不能精确表达在一个float中，那么选取下一个接近的离散值还是上一个接近的离散值是implementation defined（实现定义的——即“你可以在实现商的编译器文档中找到说明”）。这些问题会影响到你编写可移植的代码。

（注：以上只是一个不完全列表，用于演示该分类标准的意义——实际上，如果我们只考虑“80%场景下的复杂性”，记忆和学习的负担便会大大减小。）

20%场景下的复杂性：

1. 对象内存布局

2. 模板：偏特化；非类型模板参数；模板参数推导规则；实例化；二段式名字查找；元编程等等。

3. 名字查找&绑定规则

4. 各种缺陷以及缺陷衍生的workarounds（C++书中把这些叫做“技术”）：不支持concepts（boost.concept_check库）；类型透明的typedef（true-typedef惯用法）；弱类型的枚举（强枚举惯用法）；隐式bool转换（safe-bool惯用法）；自定义类型不支持初始化列表（boost.assign库）；孱弱的元编程支持（type-traits惯用法；tag-dispatch惯用法；boost.enable_if库；boost.static_assert库）；右值缺陷（loki.mojo库）；不支持可变数目的模板参数列表（type-list惯用法）；不支持native的alignment指定。

（注：以上只是一个不完全列表。你会发现，这些细节或技术在日常编程中极少用到，尤其是各种语言缺陷衍生出来的workarounds，构成了一个巨大的长尾，在无论是C++的书还是文献中都占有了很大的比重，作者们称它们为技术，然而实际上这些“技术”绝大多数只在库开发当中需要用到。）

非本质复杂性&本质复杂性

此外，考虑另一种分类办法也是有帮助的，即分为非本质复杂性和本质复杂性。

非本质复杂性（不完全列表）

1. 缺陷（指能够克服的问题，但解决方案很笨拙；C++的书里面把克服缺陷的workarounds称作技术，我觉得非常误导）：例子在前面已经列了一堆了。

2. 陷阱（指无法克服的问题，只能小心绕过；如果跌进去，那就意味着你不知道这个陷阱，那么很大可能性你也不知道从哪去解决这个问题）：一般来说，作为一个合格的程序员（不管是不是C++程序员），80%场景下的语言陷阱是需要记住才行的。比如深拷贝&浅拷贝；基类的析构函数应当为虚；缺省生成的类成员函数；求值顺序&序列点；类成员初始化顺序&声明顺序；导致不可移植代码的实现相关问题等。

本质复杂性（不完全列表）

1. 内存管理

2. 对象生命期

3. 重载决议

4. 名字查找

5. 模板参数推导规则

6. 异常

7. OO（动态）和GP（静态）两种范式的应用场景和交互

总而言之，这一节的目的是要告诉你从一个较高的层次去把握C++中的复杂性。其中最重要的一个指导思想就是在学习的过程中注意你正学习的技术或细节到底是80%场景下的还是20%场景下的（一般来说，读完两本书——后面会提到——之后你就能够很容易的对此进行判断了），如果是20%场景下的（有大量这类复杂性，其中尤数各种各样的workarounds为巨），那么也许最好的做法是只记住一个大概，不去作任何深究。此外，一般来说，不管使用哪门语言，认识语言陷阱对于编程来说都是一个必要的条件，语言陷阱的特点是如果你掉进去了，那么很大可能意味着你本来就不知道这有个陷阱，后者很大可能意味着你不知道如何解决。

学习C++：实践者的方法

在上面写了那么多之后，如何学习C++这个问题的答案其实已经很明显了。我们所欠缺的是一个书单。

第一本

如果你是一个C++程序员，那么很大的可能性你会需要用到底层知识（硬件平台架构、缓存、指令流水线、硬件优化、内存、整数&浮点数运算等）；这是因为两个主要原因：一，了解底层知识有助于写出高效的代码。二，C++这样的接近硬件的语言为了降低语言抽象的效率惩罚，在语言设计上作了很多折衷，比如内建的有限精度整型和浮点型，比如指针。这就意味着，用这类语言编程容易掉进Joel所谓的“抽象漏洞”，需要你在语言提供的抽象层面之下去思考并解决遇到的问题，此时的底层知识便能帮上大忙。因此，一本从程序员（而不是电子工程师）的角度去介绍底层知识的书会非常有帮助——这就是推荐《Computer Systems：A Programmers Perspective》（以下简称CSAPP）（中译本《深入理解计算机系统》）的原因。

第三本（是的，第三本）

另一方面，C++不同于C的一个关键地方就在于，C++在完全保留有C的高效的基础上，增添了抽象机制。而所谓的“现代C++风格”便是倡导正确利用C++的抽象机制和这些机制构建出来的现代C++库（以STL为代表）的，Bjarne也很早就倡导将C++当作一门不同于C的新语言来学习（就拿内存管理来说，使用现代C++的内存管理技术，几乎可以完全避免new和delete），因此，一本从这个思路来介绍C++的入门书籍是非常必要的——这就是推荐《Accelerated C++》的原因（以下简称AC++）。《Accelerated C++》的作者Andrew Koenig是C++标准化过程中的核心人物之一。

第二本

C++是在C语言大行其道的历史背景下发展起来的，在一开始以及后来的相当长一段时间内，C++是C的超集，所有C的特性在C++里面都有，因此导致了大量后来的C++入门书籍都从C讲起，实际上，这是一个误导，因为C++虽然是C的超集，然而用抽象机制扩展C语言的重大意义就在于用抽象去覆盖C当中裸露的种种语言特性，让程序员能够在一个更自然的抽象层面上编程，比如你不是用int*加一个数组大小n来表示一个数组，而是用可自动增长的vector；比如你不是用malloc/free，而是用智能指针和RAII技术来管理资源；比如你不是用一个只包含数据的结构体加上一组函数来做一个暴露的类，而是使用真正的ADT。比如你不是使用second-class的返回值来表达错误，而是利用first-class的语言级异常机制等等。然而，C毕竟是C++的源头，剥开C++的抽象外衣，底层仍然还是C；而且，更关键的是，在实际编码当中，有时候还的确要“C”一把，比如在模块级的二进制接口封装上。Bjarne也说过，OO/GP这些抽象机制只有用在合适的地方才是合适的。当人们手头有的是锤子的时候，很容易把所有的目标都当成钉子，有时候C的确能够提供简洁高效的解决方案，比如C标准库里面的printf和fopen（此例受云风的启发）的使用界面就是典型的例子。简而言之，理解C语言的精神不仅有助于更好地理解C++，更理性地使用C++，而且也有其实践意义——这就是推荐《The C Programming Language》（以下简称TCPL）的原因。此外，建议在阅读《Accelerated C++》之前先阅读《The C Programming Language》。因为，一，《The C Programming Language》非常薄。二，如果你带着比较的眼光去看问题，看完《The C Programming Language》再看《Accelerated C++》，你便会更深刻的理解C++语言引入抽象机制的意义和实际作用。

第四本

《Accelerated C++》固然写得非常漂亮，但正如所有漂亮的入门书一样，它的优点和弱点都在于它的轻薄短小。短短3百页，对现代C++的运用精神作了极好的概述。然而要熟练运用C++，我们还需要更多的讲解，这个时候一本全面但又不钻语言牛角尖，从“语言是如何支持抽象设计”的角度而不是“为了讲语言特性而讲语言特性”的角度来介绍一门语言的书便至关重要，在C++里面，我还没有见到比C++之父本人的《The C++ Programming Language》（以下简称TC++PL）做得更好的，C++之父本人既有大规模C++运用的经验又有语言设计思想的最本质把握，因此TC++PL才能做到高屋建瓴，不为细节所累；同时又能做到实践导向，不落于为介绍语言而介绍语言的巢臼。最后有一个需要提醒的地方，TC++PL其实没有它看起来那么厚，因为真正介绍语言的内容只有区区500页（第一部分：基础；第二部分：抽象机制；以及第四部分：用C++设计），剩下的是介绍标准库的，可以当作Manual（参考手册）。

建议3：CSAPP &TCPL& AC++&TC++PL。

是的，在C++方面登堂入室并不需要阅读多得恐怖的所谓“经典”，至于为什么这些“经典”无需阅读，前面已经讲的很详细了。其实你只需要这四本书，就可以奠定一个深厚的基础，以及对C++的成熟理性的现代运用理念。其余的书都可以当成参考资料，用到的时候再去翻阅，即：

建议4：实践驱动地学习。

实践驱动当然不代表什么基础都不打，直接捋起袖管就上。不管运用哪种工具，首先都需要知道关于它的一定程度的基本知识（包括应该怎么用，和不应该怎么用）。知道应该怎么用可以帮你发挥出它的正确和最大效用，知道不应该怎么用则可以帮你避免用的过程中伤及自身的危险。这就是为什么我建议你看四本书，以及建议你要了解C++中的陷阱（大部分来自C，因此你可以阅读《C缺陷和陷阱》）的原因。

实践驱动代表着一旦一个扎实的基础具备了之后获得延伸知识的方式。出于环境和心理的原因，C++学习者们在这条路上走错的几率非常大，许多人乃至以上来就拿Effective C++&More Effective C++、Inside C++ Object Model这类书去读（是的，我也是，所以我才会在这里写下这篇文章），结果读了一本又一本，出现知道虚函数实现机制的每个细节却不知道虚函数作用的情况。

实践驱动其实很简单：实践+查文档。知识便在这样一个简单的循环中积累起来。实践驱动的最大好处就是你学到的都是实践当中真正需要的，属于那“80%”最有用的。而查文档的重要性前面已经说过了，但对于C++实践者来说，哪些“文档”是非常重要的呢？

第二本

《C++ Coding Standard》。无需多作介绍，这是一本浓缩了C++社群多年来宝贵的经验结晶的书，贴近实践，处处以80%场景为主导，不钻语言旮旯，用本为主…总之，非常值得放在手边时时参阅。因为书很薄，所以也不妨先往脑袋里面装一遍。书中的101条建议的介绍都很简略，并且指出了详细介绍的延伸阅读，在延伸阅读的时候还是要注意不要陷入无关的细节和不必要的技巧中，时时抬头看一看你需要解决的问题。在C++编码标准方面，Bjarne也有一些建议。

第一本

《The Pragmatic Programmer》，用本程序员的杰作；虽然不是一本C++的书，但其介绍的实践理念却是所有程序员都需要的。

第三本

《Code Complete, 2nd Edition》，这是一本非常卓越的参考资料，涉及开发过程的全景，有大量宝贵的经验。你未必要一口气读完，但你至少应该知道它里面都写了哪些内容，以便可以回头参阅。

其它

所有优秀的技术书籍都是资料来源。一旦养成了查文档的习惯，所有的电子书、纸书、网络上的资源实际上都是你的财富。不过，查文档的前提是你要从手边的问题分析出应该到什么地方去查资料，这里，分析问题的能力很重要，因此：

建议5：思考。

这个建议就把我们带到了第四本书：

第四本：

《你的灯亮着吗？》。不作介绍，自己阅读，这本书只有一百多页，但精彩非常，妙趣横生。

最后，要想理性地运用一门语言，不仅需要看到这门语言的特点，还要能够从另一个角度去看这门语言——即看到它的缺点，因为从心理上——

事实10：一旦我们熟悉了一门语言之后，就容易不知不觉地在其框架下思考，受到语言特性的细节的影响，作出second-class的设计。

对于像C++这样的在抽象机制上作了折衷的语言，尤其如此，思考容易受到语言机制本身细节的影响，往往在心里头还没想好怎么抽象，就已经确定了使用什么语言机制乃至技巧；更有甚者是为了使用某个特性而去使用某个特性。然而，实际上，我们应该——

建议6：脱离语言思考，使用语言实现。

关于设计的一般理念，Eric Raymond在《The Art of Unix Programming》的第二部分有非常精彩的阐述。

此外，除了脱离语言的具体抽象机制来思考设计之外，学习其它语言对同类抽象机制的支持也是非常有益的，正如老话所说，“兼听则明”。前一阵子reddit上也常出现“How Learning XXX help me become a Better YYY programmer”（其中XXX和YYY指代编程语言）的帖子，正是这个道理，这就把我们带到了最后一个建议：学习其它语言。

建议7：学习其它语言。

如果你是一个系统程序员，你可能会觉得没有必要学习其它语言，然而未必如此，你未必需要精通其它语言，而是可以去试着了解其它语言的设计理念，是如何支持日常编程中的设计的。这一招非常有利于在使用你自己的语言编程时心理上脱离语言机制细节的影响，作出更好的抽象设计。

尾声

建议8（可选）：重读本文。

注：这篇文章的目的是给国内的C++学习者（尤其是初学者）一个可操作的建议。我打算不断修订并完善它；因为这是根据我个人的经验来写的，而基于我对C++的熟悉程度，可能会有地方并不能完完全全站到初学者的视角来看问题。我估计会有这样的地方，所以，如果有任何建议，请发邮件给我：[e-mail]

del.icio.us 标签: cplusplus

--

1. 已确认feedburner不可靠，由于全文输出之后feed庞大到了近1M，所以出现严重乱码；CSDN blog的后台编辑器对庞大的feed也有贡献（导致了大量的格式化tag），遂从这篇开始，用Live Writer写blog，输出的文本含有的格式化tag消失了。Anyway，麻烦用FB订阅的同学转为直接订阅原始rss（因feedsky抓取feed似乎也似乎时有问题）：

http://blog.csdn.net/pongba/rss.aspx

2. C++的罗浮宫已改为全文rss输出。

3. As Always，欢迎加入我们的讨论组——TopLanguage（http://groups.google.com/group/pongba），自从8月份建立以来，我们已经吸引了三百位同学，二千五百多条讨论，想知道我们讨论些什么，参见TopLanguage讨论精选[一]，精选[二]，精选[三]，加入前请看这里。