学习C++的五十个观点
老生常谈的学问。。。
条款1. 把C++当成一门新的语言学习（和C没啥关系！真的。）；
这一条源于我在《程序员》杂志2001年第4期上看到的《将标准C++视为一个新语言》一文，作者是C++的设计者Bjarne Strou- strup。这篇文章还可以在Bjarne Stroustrup的个人网页上找到。这篇及时到来的文章很好的调整了我的思维，让我有幸在初学C++时就得以拨乱反正的重新审视了C++这门语言和自己对C++的学习，同时也使我就此开始
[kingofark的收获]：经常拜读大师们的articles，追随大师们的先进思路，千万别让自己活在与大师们不同的时间里。
[参考]：
条款2. 看《Thinking In C++》，不要看《C++编程思想》；
[解说]：于此，我不再多说——因为争议太多罢。这里我向大家推荐我在《kingofark的“五评计划”》系列文章里面关于此书的一些讨论。（在撰写本文时，《kingofark的“五评计划”》已经在撰写中，相信很快能与大家见面。）
[kingofark的收获]：明白了“阴沟里也能翻船”的道理。
[参考]：
条款3. 看《The C++ Programming Language》和《Inside The C++ Object Model》,不要因为他们很难而我们自 己是初学者所以就不看；
[解说]：关于这两本书，大家也可以参考我的拙作《kingofark的“五评计划”》系列文章里面关于C++书籍的一些讨论。（在撰写本文时，《kingofark的“五评计划”》已经在撰写中，相信很快能与大家见面。）不错，这两本书的确不太容易下咽，但是大家应该（也早就应该已经）认识到：钻研精神是一个程序员必备的素质。这也是为什么我在好几个条款里说明同一个问题的原因。
[kingofark的收获]：“书山有路勤为径，学海无涯苦作舟”
[参考]：
条款4. 不要被VC、BCB、BC、MC、TC等词汇所迷惑——他们都是集成开发环境，而我们要学的是一门语言；
[解说]：
VC: Microsoft Visual C++
BCB: Borland C++ Builder
BC: Borland C++
MC: Microsoft C++
TC: Turbo C（有时也指Turbo C++）
WC: Watcom C++
各种简化了的、混杂了的口头称谓容易使初学者感到迷惑，这很正常。不过，其实只要稍加留意，这些迷惑完全可以被消除。大家可以注意以下几点：
（1） 由于C++语言（其它语言也是一样）几乎总是要以某个集成开发环境为载体、平台，才能被真正的“使用”，因此人们在口头上容易用一个集成开发环境的名字来意指一门语言（比如VC，BC，TC等）；
（2） 程序设计语言需要一种载体来被运用，这就好像汉语、英语一定要被人用嘴说出来、用笔写出来才能发挥作用一样；
（3） 编译器（或解释器）有时也被集成开发环境的名称所指代（比如“你用VC编译过吗？”实际上应该是“你用VC的C++编译 器编译过吗？”）；
（4） 只要多了解各种词汇的详细信息（一般是其英文全称），就可以很容易的发现一些你本来就该弄清楚的事情；
（5） 在口头上，也请你在不影响正常表达的情况下，尽量说得准确些，不要迷惑更多更新的初学者。
[kingofark的收获]：“我再也不学VC这门语言了。”
[参考]：
条款5. 不要放过任何一个看上去很简单的小编程问题——他们往往并不那么简单，或者可以引伸出很多知识点；
[解说]：这是kingofark我的亲身体会。
我早年学过BASIC，后来学C的时候，手里攥着一本教材，对其中的习题很不屑。有这样一道题：“编写一个程序，在屏幕上打印
*
* * *
* * * * *
* * * * * * *
要求使用本章学过的循环语句。” 其实我当时的眼光在扫到那个弱智的三角形图案时就跳到下一道题去了，全没有注意到题目最后的要求，于是脑海里很不屑的闪现出这样的一段代码：
printf(“ *\n”);
printf(“ * * *\n”);
printf(“ * * * * *\n”);
printf(“ * * * * * * *\n”);
……
几个星期之后，我在翻书时很偶然的瞥见了这道题的后半部分要求，心里生疑：“这么简单的打印问题干嘛用循环？”于是重新审题。 这一次，我的脑子里再也没有闪出东西——唔，除了问号以外——于是忍不住开始编写程序。结果“不编不知道，一编死翘翘”， 在经过了半天的捉摸之后，才终于有了一个正确的答案。从此明白了：哦，要先在草稿纸上设计一下，不能光凭脑子想；哦， 打印一个三角形还可以用这么巧妙的循环；哦，……“但这完全是你自己没有认真看题造成的吧！？”你可能会抱怨我说跑题了， “这跟本条款有何干？”好吧，如果上面的故事算是跑题的话，那么现在题跑完了。在经过了那段学习打印“*”的初期，书上的习题也越来越不容易，其中有这么一道：“编写一个程序，要求输入任意十进制数，在屏幕上显示相对应的十六进制数。” “很简单嘛，”我又想着（嗯？我怎么会说“又”这个字？），脑子里闪现构思若干：定义一个int decimal_val，由用户赋值 后，再通过相应的计算转成十六进制就可以了嘛。”三下五除二，程序出来了，得意洋洋，忍不住叫父亲来看。早年做过计算机工作者的父亲看了我运行程序演示，对我说：“输入的数值太有限了，只能转换int级的数值。”“那简单！”我更得意了，“把int改为long int，不，改为long long int，……呃？”问题忽然严重了：习题要求能转换“任意十进制数”，但即使是 long long long long int，也还是有限的。怎么办？父亲只说：“是不是可以考虑用char数组来接收用户的输入，这样可以 支持任意长的输入，就是转换十六进制的方法要重新设计了。”一个星期之后（噢，是的，那时我很笨），我终于可以在朋友面前 炫耀我的“超级转换程序”了。
[kingofark的收获]：“麻雀虽小，五脏俱全”
[参考]：
条款6. 会用Visual C++，并不说明你会C++；
[解说]：Visual C++这个集成开发环境的确为我们提供了很多的东西，包括巨大的MFC（Microsoft Foundation Class），可爱的按 钮啦，很“专业”的帮助窗口啦，让人很有成就感的about窗口啦，等等。然而，特定程序的核心算法还是需要我们自己来提供，适合 特定程序的类还是需要我们自己来派生和管理，大部分特定程序的数据结构还是需要我们自己来实现——只不过我们是在VC的帮助下做 其中一些事情罢了。很多人都曾向我声称他“会”VC了。但除了书上的例子，他们什么都做不出来。之所以称VC为“集成开发环境”， 就是因为其本身是作为承载C++的一种“环境”而存在的，C++才是我们所要关注的主体。 有了球场边球迷们的欢呼、喝彩和助威，足球运动才越发体现出其无比的魅力。然而我们踢的仍然是足球，不是场边的球迷。VC与C++之关系亦包含有相似的道理。
[kingofark的收获]：一脚出去，不要踢错了对象。
[参考]：
条款7. 学class并不难，template、STL、generic programming也不过如此——难的是长期坚持实践和不遗余力的博览 群书；
[解说]：哈哈，这句话的的确确是我鼓励初学者的话。毕竟从技术上讲，STL和范型技术的的确确不能像著名主持人崔永元给自传起名字那样 被概括为“不过如此”。我认为，长期坚持实践和不遗余力的博览群书，是一个程序员的根本治学之道。虽然谁都知道这是一个多少 有些完美的期望，但它毕竟是期望而不是奢望——总可能实现罢。
[kingofark的收获]：应该仔细研读和体会U2乐队的一首名曲《I’m still haven’t found what I’m looking for》的歌词，这样，在人生的任 何一个高度上驻足思考时，都不至于忘记了自己所追寻的一切。
条款8. 如果不是天才的话，想学编程就不要想玩游戏——你以为你做到了，其实你的C++水平并没有和你通关的能力一起 变高——其实可以时刻记住：学C++是为了编游戏的；
[解说]：只说三点：
（1）www.1cplusplusstreet.com上面就有很多利用编写游戏来学习C++的有趣内容，相当的好；
（2）很多著名的游戏也都是有源代码可看的；
（3）Open Source的资源也是大家学习的好地方。
[kingofark的收获]：过分热衷于电子游戏的人大约有两种“通关方法”：
（1） 酷爱游戏—＞玩游戏—＞还想玩游戏—＞还想玩游戏—＞还想玩游戏—＞成为超超超……（汗）级玩家；
（2） 酷爱游戏—＞玩游戏—＞改游戏—＞对游戏的制作产生好奇—＞钻研游戏的开发知识—＞成为有潜力/有实力的业余/专业游戏开发者。
[参考]：
条款9. 看Visual C++的书，是学不了C++语言的；
[解说]：一句话：集成开发环境是掌握在厂商手里的；语言是掌握在自己手里的。
[kingofark的收获]：“哦，你看了很多VC的书？挺好挺好。对了，顺便问一下，你会用C++吗？”
[参考]：
条款10. 浮躁的人容易说：XX语言不行了，应该学YY；——是你自己不行了吧！？
条款11. 浮躁的人容易问：我到底该学什么；——别问，学就对了；
条款12. 浮躁的人容易问：XX有钱途吗；——建议你去抢银行；
条款13. 浮躁的人容易说：我要中文版！我英文不行！——不行？学呀！
条款14. 浮躁的人容易问：XX和YY哪个好；——告诉你吧，都好——只要你学就行；
条款15. 浮躁的人分两种：a)只观望而不学的人；b)只学而不坚持的人；
条款49. 请不要做浮躁的人；
[解说]：写下这样的条款，一定不免招致异议者的不屑一顾甚或是口水，但我在论坛上看到的确是事实：“XX语言不行了，应该学YY！”、 “我到底该学什么？”、“XX有钱途吗？”、“我要中文版！我英文不行！”、“XX和YY哪个好？”……这样的“问”、“话”见得多了， 我不禁想起鲁迅先生在《〈呐喊〉自序》中的一段文字：——“假如一间铁屋子，是绝无窗户而万难破毁的，里面有许多熟睡的人们， 不久都闷死了，然而是从昏睡入死灭，并不感到就死的悲哀。现在你大嚷起来，惊醒了较为清醒的几个人，使者不幸的少数者来受无
可挽救的临终的苦楚，你倒以为对得起他们么？”——“然而几个人既然起来，你不能说决没有毁坏这铁屋的希望。” 我想，我不仅愿意做那个大嚷起来的人，而且还要说：“或许我们的铁屋子至少还有窗和门罢。”
[kingofark的收获]：以平和的心态做学问。
[参考]：
条款16. 把时髦的技术挂在嘴边，还不如把过时的技术记在心里；
[解说]：这里还是强调了一个人学习要踏实的道理。总听到很多人不屑的说某某技术已经过时，学了也没用之类的话。其中屡被攻击的对象 比如dos啦，mode 13h啦，win3.1啦，VGA啦，甚至是win95、Pascal、C、C++等等。这些人是浮躁的（见
条款10），一味追求“新”技术，殊不知“新”技术、“新”理论无不是在传承着前人智慧点点滴滴的精华。我最熟悉的一个例子就是那
本Michael Abrash著的《Michael Abrash’s Graphics Programming Black Book Special Edition》。这本堪称图形程序设计领域经典之作的宏篇巨著中充满了对VGA、286、mode X、256色等的讨论和研究。“啊哈，你说的这些可是真的过时了，”我开始听到有人在说了。过时了吗？我的回答既是肯定的又是否定的。的确，随着计算机技术的飞速发展，可能不会再需要用到mode X来编写图形程序了；是的，256色已经不堪入目了；不错，win3.1已成昨日黄花。但是，各位眼光颇“高”的朋友啊，千万不要忘记学习的真正目的。小时候我常为学业而困扰，成绩也不佳。每逢考试分数不理想，总是怀着沉重的心情跺回家，对未来的学习也产生了绝望的忧虑。每一次，父亲总是轻轻的拍拍我的头，轻声说道：“没关系，以后努力就行了。学习本身就是就是一种磨练，学习的目的就是磨练你的意志。通过学习的过程来经受各种各样的考验，自己才会慢慢变得能够克服生活中遇到的各种各样的事情。考试也是一种磨练，没什么好担心的，别怕。”
《Michael Abrash’s Graphics Programming Black Book Special Edition》蕴含了作者Michael Abrash浸淫
图形程序开发领域数十年的经验积累，其博大精深的优化理念才是赢得读者、专家们撕声喝彩的真正原因（熟悉Quake这个电子游戏的朋友们也一定知道 Michael Abrash对其的贡献）。试问当今各路英雄高手，谁敢站出来不屑的说：“我不需要优化技术？” 不需要吗？需要吗？不需要吗？需要吗？不需要吗？……
唔，我想这个问题的答案大家心里都明白。
[kingofark的收获]：即使是粪便也不是全没有价值的，更何况一堆夹杂着钻石的黄金。
条款17. C++不仅仅是支持面向对象的程序设计语言；
[解说]： 向大家强力推荐C++的设计者Bjarne Stroustrup的一篇文章《Why C++ is not just an Object-Oriented
Programming Language（为什么C++不仅仅是一门面向对象程序设计语言）。这篇文章在他的个人网页上能够找到。
[kingofark的收获]：其实很多基本但重要的观点都是出自领域内大师们的所文所言，我只是在不遗余力的复述这些观点罢了。
条款18. 学习编程最好的方法之一就是阅读源代码；
[解说]：这是世界公认的，著名的权威专家，已逝的Richard Stevens博士平生一贯坚持的观点。我们从他所著的经典书籍中可以看到这一点。一本《TCP/IP Illustrated Volume II》（TCP/IP详解 卷二），就原汁原味的包含了BSDLite4.4中的1,5000行代码，很现实的将此书的读者带入了一个真正的编程世界。当然这本书中的程序都是C代码，学习C++者并非一定要看，这里只是举个例子来说明问题。 学习的条件提供给你了，现在就看你自己的了。
[kingofark的收获]：选择题：要在天空中翱翔，最好的办法是：
A.自己做一个翅膀，从悬崖上一跳；
B.自己做一架滑翔机，找一块平坦的荒地借着风起飞；
C.驾驶一架性能良好的飞机，在修建好的跑道上起飞；
D.乘坐飞机到高空，然后背上降落伞（或许还带一个滑板），跳出飞机。
我选择D。
[关于本条款的解说]：详
“这是世界公认的，著名的权威专家，已逝的Richard Stevens博士平生一贯坚持的观点。我们从他所著的经典书籍中可以看到这一点。一本《TCP/IP Illustrated Volume II》（TCP/IP详解 卷二），就原汁原味的包含了BSDLite4.4 中的1,5000行代码，很现实的将此书的读者带入了一个真正的编程世界。Linux蓬勃发展起来了；OpenSource运动越来越壮大；《莱昂氏 UNIX源代码分析》、《Linux内核源代码分析》、《Linux IP栈源代码分析》以及《Apache服务器源代码分析》相继出版了。学习的条件提供给你了，现在就看你自己的了。”
孟岩先生（myan）对这个解说给出了如下看法：
“关于条款18，你举的几个源代码例子实在有误导之嫌：全是OS/TCP/IP源码，全是C源码，而且就我所读过的Linux源码来讲，为了追求速度，使用了大量黑客技巧。初学者在还没有形成正确观念之前，如果迷恋上这些技巧，就会迷失大方向，失去真正C++ 风格。” 然后，他又作了如下的建议： “关于C++源代码，从编程风格上，GP方面的我比较推崇STL和Boost库。但是毕竟是库代码，对于大部分人还是有误导性。ACE/TAO据说是非常好的源码范本，可惜我的网络编程知识很欠缺，无法根据自己的体验给出建议。对于普通应用，还真难找到风格和组织俱佳的源码范本。比如像 wzWindows, Mozilla，一上来就把template，多继承等特性给禁止掉，不足以为道。微软的ATL和WTL围绕COM展开，需要很多的基础知识，C++的运用方面还是比较出色，就是代码里还是夹杂了大量的宏。总之，C++ 98风格的优秀源码，现在还很难找到。如果实在要读，我还是推荐STL/Boost。尤其是Boost里面有一些层次较高的库，比较 接近用户代码，可以很好的借鉴。” 的确，要找“风格和组织俱佳”的源代码拿来学习并不是太容易，所以我以为，“如果实在要读”，则完全可以到国内外（尤其是国外）相关C++的网站上去找。极品稀少，我们暂时也只好转而求其次，但是，像我在条款8中推荐的那种比较优秀的C/C++资源网站还是很多的，比如www.programmersheaven.com，比如www.codeproject.com。我觉得我们求的这个“次”也并非不够我们学的。这里我再次感谢孟岩先生（myan）以及其他帮助过我的人！
条款19. 在任何时刻都不要认为自己手中的书已经足够了；
[解说]：（1） 计算机技术正以飞快的速度发展和翻新。新技术取代旧技术时发出的兴奋呻吟声此起彼伏，被我们听到。哦，其实那并非呻吟声，而只是有人在用另一种语言说“活到老，学到老”这句话的声音。
（2） C到标准C，C++到标准C++。很多固有的东西也在长肉补血，发展进化。我们要认识到这种改变，跟随发展的脚步。毕竟“发展才是硬道理”。有很多东西把这一切的一切跟你紧密的联系起来。其中之一是书籍。
[kingofark的收获]：把“噢，我的上帝！”改为“噎，我的书！”
条款20. 请阅读《The Standard C++ Bible》(中文版：标准C++宝典)，掌握C++标准；
[解说]：这里强调的，还是要紧跟C++发展方向，把C++学准，学精。关于《The Standard C++ Bible》（中文版：标准C++宝典）的讨论，我放在我的系列拙文《kingofark的“五评计划”》中进行。
[kingofark的收获]：标准就是标准，不服不行，不学不行，不用不行，不改进不发展不行。
条款21. 看得懂的书，请仔细看；看不懂的书，请硬着头皮看；
[解说]：小孩子刚生下来，是不会说哪门语言的，当然更是听不懂的，只能“硬着头皮”听爷爷奶奶爸爸妈妈哥哥姐姐叔叔阿姨伯伯婶婶说话，听得久了，就会了。学习本身就是一个从不会到会，从不熟悉到熟悉，从不懂到懂的过程。看不懂就不看，等于什么都不看。除此之外，这一点也没什么理由好说的了。如果非要说的话，一来连鲁迅先生笔下的阿Q都懂得“凡事总须研究才能明白” 的道理；二来嘛，总是看些自己轻车熟路的东西，你不觉的太没有挑战性了吗？
[kingofark的收获]：其实阿Q也不是没有优点的啦！
[参考]：
条款22. 别指望看第一遍书就能记住和掌握什么——请看第二遍、第三遍；
[解说]：说实话，写到这个条款的时候，我都不想再写下去了——因为道理太简单，大凡正常的、读过书的人都知晓。连一些情节简单的电视连续剧都有人要一本正经的看了又看仔细回味（kingofark就不止一遍的看日本连续剧《GTO》和《続?星の金貨》），作为智慧集合的书就更是如此。
[kingofark的收获]：爱吃回锅肉的人也许更容易体会这个道理。
[参考]：
条款23.请看《Effective C++》和《More Effective C++》以及《Exceptional C++》；
[解说]：这里建议大家看看侯捷先生的一篇文章《拳拳到肉 掷地铿锵的三本 OOP 绝佳小书》。文章可以在侯捷先生的网站上面找到。大家在这里就先窥其一角吧：
“拿破仑虽然是个矮个子，一生叱吒却俨然历史的巨人。今天我要介绍的三本书，虽然轻薄短小有如拿破仑的身材，在 C++ /OOP 领域里，其份量与影响却也有着拿破仑般的辉煌灿烂。说它们轻薄短小，是的，让数字说话：三本书合起来才256+318+208=782 页，只比 C++ 语言知名教本 C++ Primer 3/e一半篇幅再多一些而已，比起 C++ 语言权威着作 The C++ Programming Language 3/e 也才达到三分之二的页数份量。逛书店时一个不留神，只怕你便遗漏了这些小书的存在。但如果你真遗漏了它们的存在，实在是你的莫大损失。就我个人的编程经验，以及我的教学经验（对象为业界工程师或 大学生），只要是 C++/OOP 设计思维与语言运用本身的问题，非关 problem domain，百分之九十以上皆可在这三本书籍中找到直接或间接的答案。” “以上三本小书的功用不仅在提纲契领地点出重点，也在於对每个主题有深刻的讨论。在这些书籍中，你会发现一些忠告，告诉你应该做些什麽，为什麽如此；也告诉你不应该做些什麽，又为什麽如此。基本而言当然 whys 比 whats 更重要，这便是这些书籍最有价值的地方。至於从速食的角度来看，检阅一系列准则，也比强记一或二本庞杂的教科书更轻松方便得多。”
[kingofark的收获]：领会了这三本书的内涵，你一开始就可以用比圣斗士星矢更高的嗓门儿厉声嘶道：
“爆发吧，我的小宇宙！！！！！！” ——而且百分之百可以爆发——大可不必像星矢那样每次先被打个稀烂才后发制人。
[参考]：侯捷先生的书评。
条款24.不要停留在集成开发环境的摇篮上，要学会控制集成开发环境，还要学会用命令行方式处理程序；
[解说]：有些不爱钻研的初学者（比如kingofark）甚至连一个集成开发环境十分之一的功能都没有用到。这是一种非常不好的学习状况，应该改变。其实再复杂的集成开发环境也不过就是个工具软件。连软件本身都用不好，那还怎么去做软件？拜托！高级语言还没有发展到可以完全摆脱命令行操作的阶段。在真正的底层，命令行还是不可或缺的。如果你不这么认为，那就说明你的思想够先进——如果你是站在未来人的角度思考的，我承认我争不过你（因为你不可理喻）。
[kingofark的收获]：只摸一下饭碗，是填不饱肚子的；只与情人接吻，情人也是生不了孩子的；光会撒尿不会拉屎，人也是不畅通的。这些道理你都懂，怎么一学编程都晕了？
条款25. 和别人一起讨论有意义的C++知识点，而不是争吵XX行不行或者YY与ZZ哪个好；
[解说]：特别把这句话从“浮躁”的种种表现里挑出来，是因为想向大家强烈推荐侯捷先生的文章《漫谈程序员与编程》。该文刊登在《程序员》杂志2001年第5，6期上；在侯捷先生的网站上也能找到。文中专门以小标题“口舌之战有何益”讨论了这方面的问题，希望大家好好消化。
[kingofark的收获]：好羡慕哑巴。
[参考]：
条款26. 请看《程序设计实践》，并严格的按照其要求去做；
[解说]：机械工业出版社的《程序设计实践》，愿书名为《The Practice of Programming》，由B.Kernighan和Rob Pike这一对技术书籍黄金搭档合著。该书轻薄短小，却包含了两位著者浸淫程序设计领域多年经验的积累和总结，从极具现实性和艺术性的角度讲述了程序设计时需要注意的多方面问题，强调程序设计并不仅仅是编码的观点。精心选择的素材、体贴的叙述方式（还包括上佳的翻译），都使你能够在不经意的字里行间得到丰厚的收获——真的，基本上是天上掉馅饼，你唯一的付出就是张嘴吐出一句“哦，原来是这样的啊！”看看两位著者是如何在本书的前言中说到大家心坎儿上的吧： “你是否曾：浪费了许多时间去对一个错误算法做编码？ 使用了一个过于复杂的数据结构？ 测试一个程序而忽略了其中最简单的问题？ 花了一整天功夫查找一个错误，实际上却应该是在5分钟里就找到它？ 需要让一个程序运行速度快3倍而且使用更少的存储？ 费劲的把一个工作站上的程序移到PC上，或者相反？ 试图对其他人写的某个程序作最简单的修改？ 重写一个程序，原因是你根本无法理解它？这些事都很有趣吗？” 请大家好好体会两位程序设计领域的中流砥柱在风格、算法与数据结构、设计与实现、界面、排错、测试、性能、可移植性和记法这些方面的谆谆教导。
[kingofark的收获]：读完这本书后，才发现自己以前曾是个傻子；这本书连傻子都能看懂；这本书能使傻子恢复成优秀的程序员。
条款27. 不要因为C和C++中有一些语法和关键字看上去相同，就认为它们的意义和作用完全一样；
[解说]：C++里面的很多“C的东西”其实都已经不完全是所谓“C的东西”了。C++中的const、struct等等的含义与C中的相比，小有不同矣！关于这一点，还是希望大家多看看书。复用（reuse）我在条款20里的一句话说就是“把C++学准，学精。”
[kingofark的收获]：求精求准，把握分寸，这是大凡天下事的道理，根本用不着kingofark在这里放气。
条款28. C++绝不是所谓的C的“扩充”——如果C++一开始就起名叫Z语言，你一定不会把C和Z语言联系得那么紧密严正声明：对本条款的解说方式决不是kingofark偷懒的表现。详情见本文的后记。
[解说]：请参考条款1。（完）（吐舌头）
条款29. 请不要认为学过XX语言再改学C++会有什么问题——你只不过又在学一门全新的语言而已；
[解说]：同条款28的解说。（又吐舌头）
条款30. 读完了《Inside The C++ Object Model》以后再来认定自己是不是已经学会了C++；
[解说]：关于《Inside The C++ Object Model》：
“C++成山似海的书籍堆中，这一本不是婴幼儿奶粉，也不是较大婴儿奶粉，它是成人专用的低脂高钙特殊奶粉。” 任何技术，习其表皮，即可把玩；探其隐匿，则能熟悉；得其精髓，方可掌故之，如使双手般精良到位。人们对“会”这个字有着不同层次的理解。我以为，通常我们应该以最狭义的方式去理解它。这不是在苛求自己，而是在检查自己是不是足够浮躁。
[kingofark的收获]：沉着的对自己说：“我什么都不会！”。
条款31. 学习编程的秘诀是：编程，编程，再编程；
[解说]：“实践是检验真理的唯一标准”。这句话连中学课本中都有。
其实，“实践”不仅具有检验真理的功能，它还碰巧是个精干的多面手，可以帮助大家做很多事情——只要你诚心聘请它就可以了，甚至连免费咨询电话都不用打——心诚则灵。不说了——大道理，说起来太张扬，恐有人给我带一顶“教条主义”的帽子。
[kingofark的收获]：有些道理很大（甚至比太阳还大），但是真正懂它的人的数目却很小。
条款32. 请留意下列书籍：《C++面向对象高效编程（C++ Effective Object-Oriented Software Construction）》
《面向对象软件构造(Object-Oriented Software Construction)》《设计模式（Design Patterns）》
《The Art of Computer Programming》；
[解说]：对书籍的讨论，我留在我的系列拙文《kingofark的“五评计划”》中慢慢进行。这里只想指出一点：《C++ Effective Object-Oriented Software Construction》一书在国外已经有了第二版了。
条款33. 记住：面向对象技术不只是C++专有的；
[解说]：同条款17。
条款34. 请把书上的程序例子亲手输入到电脑上实践，即使配套光盘中有源代码；
[解说]：自己输入源代码，且不说可以练指法，它还是一种研读代码的过程，这道理与看不懂原文就翻译不好文章一样。自己一字一句读过，才有可能通过键盘输入，于是自己在不知不觉中就已经读过一遍代码了。我们常说代码总须多读才能明白些，难道你就愿意通过使用源代码光盘的卑鄙手段来放弃自己多一次的仔细阅读机会吗？有人说用源代码光盘也能读代码。然而应该思考这样一点：只看光盘上的源代码，并不能保证你不一目十行、草草了事；而对着书输入源代码，你就不可能一目十行，因为那样的话你根本无法从键盘输入。想想这两者之间种种潜在的差距吧！我想我们还是踏实一点为好。
[kingofark的收获]：光盘上存储的仅仅只是供参考的源代码，不是研读带来的收获。
条款35. 把在书中看到的有意义的例子扩充；
[解说]：同条款5。
条款36. 请重视C++中的异常处理技术，并将其切实的运用到自己的程序中；
[解说]：这一条基本上是在对我自己敲警钟。
早年学习C++的时候，国外的C++书籍还没有引进。至于当时国内的C++教材，要是参差不齐我倒可以满足了（因为毕竟“参差不齐” 意味着并非没有好的），可偏偏就是一律整齐。那些教材的作（抄？）者，大凡把C教材的制作班底拿来remake一下，然后又贴上一些诸如inline、 class、exception这样一些时髦的标签，再大喊一声“cut!”，即宣布一切搞定了，连take 2都用不着 [注：哦，这都是做影评（经常说“这个续集只不过是正集的一个remake”之类的话）、拍电影（导演喊“cut!”）、录音乐（录制take 1，take2等）使用的术语]。在这些“C++教材”中，很多C++的重要特性都被作为一个小到令人乍舌的章节来介绍，活像影片中闪现不到半秒钟的色情镜头——想看的人心中大呼不过瘾，不想看的人则吃惊中带些厌恶。结果我当时几乎没学过异常处理的知识。现在国内外优秀的C++书籍多了，我才得以重新完整的学习C++。这一次，我可不能再学不伦不类的“C Remake++”语言了。
条款37. 经常回顾自己以前写过的程序，并尝试重写，把自己学到的新知识运用进去；
[解说]：除了参考条款5之外，还想补充一点：本观点并不是想暗示大家应该对C++的各个方面内容一字排开并按某种顺序学习，而只是说明在不断学习提高的过程中，自己的实践经验也应该得到相应的积累。其实我觉得要把这件事做好，涉及到比想象中更多的事情，其中至少包括为自己的程序做文档以便于日后查看、重读。这件事真是说来容易做来难，我们还有很多需要努力的地方，不是吗？
条款38. 不要漏掉书中任何一个练习题——请全部做完并记录下解题思路；
[解说]：同条款5。
条款39. C++语言和C++的集成开发环境要同时学习和掌握；
[解说]：见条款6。
条款40. 既然决定了学C++,就请坚持学下去，因为学习程序设计语言的目的是掌握程序设计技术，而程序设计技术是跨语言的；
[解说]：这里说的“坚持”，绝不意味着迷信和狂热的崇拜（参见条款50），而应该意味着不浮躁，能够静下心来，扎扎实实打好基础。
[kingofark的收获]：抗拒浮躁的过程有一点点像憋尿，当然两者的结果和产生的影响大不相同。
[参考]：
条款41. 就让C++语言的各种平台和开发环境去激烈的竞争吧，我们要以学习C++语言本身为主；
[解说]：见条款6和条款9。
条款42. 当你写C++程序写到一半却发现自己用的方法很拙劣时，请不要马上停手；请尽快将余下的部分粗略的完成以保证这个设计的完整性，然后分析自己的错误并重新设计和编写（参见43）；
条款43. 别心急，设计C++的class确实不容易；自己程序中的class和自己的class设计水平是在不断的编程实践中完善和发展的；
[解说]：古墓丽影（Tomb Raider）这个游戏想必大家都已经很熟悉了。当《古墓丽影：最后的启示（Tomb Raider : Last Revelation）》正式发行后，我和好友当然也乐此不疲的买了游戏光盘，和性感美丽的Lara Croft在3D世界中同甘共苦。事情就这样开了： 好友忽然有一天在电话中告知我说，Lara要与一个巨大的石头脸进行一种规则较为简单的格子棋游戏。棋盘是单向无环路的，有起点和终点；下棋双方每边各有三个棋子，通过随机的方式得到一定范围内的步数来走棋；正常情况下，每一方每次只有一次确定步数的机会并只能选一个棋子走棋；如果被移动的棋子在移动后停在某些特定的位置上，那就可以再走一次棋；特别的，如果得到的步数是某些特定的数字，则也可以再走一次棋；谁先把自己的三个棋子走完就算谁赢。我们讨论了半天，觉得这个简单的游戏可以很容易写出C++代码来，于是就开始做设计。虽然朋友很快就退出改玩游戏去了，但还是给了我很多建议。第一遍设计出来之后，我养成的种种坏习惯复发了。等到代码成形，里面已经充斥着杂乱的结构体和全局变量了。而且由于抽象的不合理，代码中处处都存在着重复的代码段。看着一堆垃圾般的代码，我的信心好像碰到异物的蜗牛触角一样刹那间飞也似的缩走了，。然而，不能接受“程序甚至还不能编译执行”这样一个事实的我不能释怀，只好硬着头皮继续写下去，越写越看出自己代码中的龌龊。结果当然是bug满宇宙飞，想修改都不容易了。只好作罢，继续自己每天正常的C++学习。若干个月之后，当我偶然从废纸堆中翻到那个bug.exe的原始设计草稿时，我又忍不住重新思考这个问题了。几个月的C++学习毕竟不是全没有作用，因此在充分认识到以前代码的缺陷的前提下，我的脑海里涌出了许多新思路，真所谓长江后浪推前浪……现在回想起来觉得，倘若当时第一次就半途而废，或许还不会对其中的不足之处有那么深的印象。这才发觉差劲的代码原来也是搞自我批评的重大阵营。
[kingofark的收获]：做什么事都不要虎头蛇尾。就连把坏事做一半所得到的教训，也不如把坏事做完得到的教训深刻。
条款44. 决不要因为程序“很小”就不遵循某些你不熟练的规则——好习惯是培养出来的，而不是一次记住的；
[解说]：参见条款26。
条款45. 每学到一个C++难点的时候，尝试着对别人讲解这个知识点并让他理解——你能讲清楚才说明你真的理解了；
[解说]：这个道理涉及到一些鲜为人知的一系列心理学、教育学方面的问题，我不在此累述。大家只用记住：转述的过程，也是人们常说的 “把知识变成自己的”之过程的一种表现形式。
[kingofark的收获]：题外话：有学问的老师未必讲课讲得好；讲课讲得好的老师未必有学问，但他/她总能把自己懂的那一部分知识讲清楚。我更喜欢后一种老师。
条款46. 记录下在和别人交流时发现的自己忽视或不理解的知识点；
[解说]：当你发现别人比你知道得多的时候，你不羡慕吗？不嫉妒吗？不敬佩吗？不崇拜吗？不自卑吗？不想超过他吗？随身带张纸，带支笔，并不会累死你的。
[kingofark的收获]：就算是天上真的掉下馅饼了，也还是需要你伸手去捡着吃的。如果你仅仅因为懒得伸手而不去吃，那可就比迷信“天上掉馅饼”的人还要可悲了。
条款47. 请不断的对自己写的程序提出更高的要求,哪怕你的程序版本号会变成Version 100.XX；
[解说]：同条款37。
条款48. 保存好你写过的所有的程序——那是你最好的积累之一；
[解说]：理由一：如果你不保存好，就无法遵守条款35，37，47了；
理由二：越来越多的代码多少会给人一种成就感，可以在不经意之间增强自信心。
[kingofark的收获]：理由三：万一自己以后出了名，还可以在电视直播或者自传里面把代码拿出来，作为训诫后人、为人师表的本钱，谱写一曲老当益壮的精神文明凯歌。
条款50. 请热爱C++!
[解说]： 请热爱C++，但是切忌蜕变成目光短浅的、迷信C++的狂热分子。
[kingofark最后的收获]：对C++说：“Everybody says I love you but no more.”
[K’s 50 PV 后记]：回顾这50条，揪心的发现其中有许多的重复观点，只是用了不同的表述而已。 这也与< K’s 50 PV>的成因有关。 最初是在CSDN的论坛上看到一篇人气颇旺的贴文，讨论些学习C/C++的经验，忽然使我有了对过去学习的感触，一些自己揣摩的文字猛然间如滔滔江水连绵不绝，又如黄河泛滥一发不可收拾，死心塌地、义无反顾的从脑海里泄将出来。 其实最后写出来的，无非是些众所周知的“耳茧增长因子”，全没有女人裸体见情人般的光彩。但自己还是不免浮躁的得意起来，淫笑着将这些文字发成贴子，收获了一次在公共场所署上自己大名的快感。等到我严肃得要给她写注解的时候，才很尴尬的注意到自己的无知与浅薄。于是很无能的继续写下去。这一次，便有了女人裸体见陌生人的尴尬——还是全裸。惭愧、羞愧一并涌上脸来，铁青。 无地自容。是以为记。