关于C++

Bjarne 一再强调,C++ 支持多种编程范式:
1.面向过程(也就是函数调用.c语言中最基础的)
2.基于数据抽象(abstract data type)
3.面向对象(object-oriented)
4.generic programming

Bjarne 指出,C++一开始的目的不是为了支持面向对象编程.客观上,c++的出现促进了面向对象编程技术的发展.
我个人认为,面向对象和generic programing 都是位于同一层面上的的.他们都是基于数据抽象技术之上.而他们的基础都是面向过程.面向对象和generic之间的结合使用,会产生许多强大的功能.

只有无聊、懒惰、浮躁的人就会整天唠唠叨叨谈论“XX 与 XX 哪个强”或者“XX落伍了”。

C++程序的高效率/无依赖性都是独一无二的,而且它的STL提供了现有语言中最强大的数据结构与算法的支持

　　1.把C++当成一门新的语言学习（和C没啥关系！真的。）；
　　2.看《Thinking In C++》，不要看《C++变成死相》；
　　3.看《The C++ Programming Language》和《Inside The C++ Object Model》,不要因为他们很难而我们自己是初学者所以就不看；
　　4.不要被VC、BCB、BC、MC、TC等词汇所迷惑——他们都是集成开发环境，而我们要学的是一门语言；
　　5.不要放过任何一个看上去很简单的小编程问题——他们往往并不那么简单，或者可以引伸出很多知识点；
　　6.会用Visual C++，并不说明你会C++；
　　7.学class并不难，template、STL、generic programming也不过如此——难的是长期坚持实践和不遗余力的博览群书；
　　8.如果不是天才的话，想学编程就不要想玩游戏——你以为你做到了，其实你的C++水平并没有和你通关的能力一起变高——其实可以时刻记住：学C++是为了编游戏的；
　　9.看Visual C++的书，是学不了C++语言的；
　　10.浮躁的人容易说：XX语言不行了，应该学YY；——是你自己不行了吧！？
　　11.浮躁的人容易问：我到底该学什么；——别问，学就对了；
　　12.浮躁的人容易问：XX有钱途吗；——建议你去抢银行；
　　13.浮躁的人容易说：我要中文版！我英文不行！——不行？学呀！
　　14.浮躁的人容易问：XX和YY哪个好；——告诉你吧，都好——只要你学就行；
　　15.浮躁的人分两种：a)只观望而不学的人；b)只学而不坚持的人；
　　16.把时髦的技术挂在嘴边，还不如把过时的技术记在心里；
　　17.C++不仅仅是支持面向对象的程序设计语言；
　　18.学习编程最好的方法之一就是阅读源代码；
　　19.在任何时刻都不要认为自己手中的书已经足够了；
　　20.请阅读《The Standard C++ Bible》(中文版：标准C++宝典)，掌握C++标准；
　　21.看得懂的书，请仔细看；看不懂的书，请硬着头皮看；
　　22.别指望看第一遍书就能记住和掌握什么——请看第二遍、第三遍；
　　23.请看《Effective C++》和《More Effective C++》以及《Exceptional C++》；
　　24.不要停留在集成开发环境的摇篮上，要学会控制集成开发环境，还要学会用命令行方式处理程序；
　　25.和别人一起讨论有意义的C++知识点，而不是争吵XX行不行或者YY与ZZ哪个好；
　　26.请看《程序设计实践》，并严格的按照其要求去做；
　　27.不要因为C和C++中有一些语法和关键字看上去相同，就认为它们的意义和作用完全一样；
　　28.C++绝不是所谓的C的“扩充”——如果C++一开始就起名叫Z语言，你一定不会把C和Z语言联系得那么紧密；
　　29.请不要认为学过XX语言再改学C++会有什么问题——你只不过又在学一门全新的语言而已；
　　30.读完了《Inside The C++ Object Model》以后再来认定自己是不是已经学会了C++；
　　31.学习编程的秘诀是：编程，编程，再编程；
　　32.请留意下列书籍：《C++面向对象高效编程（C++ Effective Object-Oriented Software Construction）》《面向对象软件构造(Object-Oriented Software Construction)》《设计模式（Design Patterns）》《The Art of Computer Programming》；
　　33.记住：面向对象技术不只是C++专有的；
　　34.请把书上的程序例子亲手输入到电脑上实践，即使配套光盘中有源代码；
　　35.把在书中看到的有意义的例子扩充；
　　36.请重视C++中的异常处理技术，并将其切实的运用到自己的程序中；
　　37.经常回顾自己以前写过的程序，并尝试重写，把自己学到的新知识运用进去；
　　38.不要漏掉书中任何一个练习题——请全部做完并记录下解题思路；
　　39.C++语言和C++的集成开发环境要同时学习和掌握；
　　40.既然决定了学C++,就请坚持学下去，因为学习程序设计语言的目的是掌握程序设计技术，而程序设计技术是跨语言的；
　　41.就让C++语言的各种平台和开发环境去激烈的竞争吧，我们要以学习C++语言本身为主；
　　42.当你写C++程序写到一半却发现自己用的方法很拙劣时，请不要马上停手；请尽快将余下的部分粗略的完成以保证这个设计的完整性，然后分析自己的错误并重新设计和编写（参见43）；
　　43.别心急，设计C++的class确实不容易；自己程序中的class和自己的class设计水平是在不断的编程实践中完善和发展的；
　　44.决不要因为程序“很小”就不遵循某些你不熟练的规则——好习惯是培养出来的，而不是一次记住的；
　　45.每学到一个C++难点的时候，尝试着对别人讲解这个知识点并让他理解——你能讲清楚才说明你真的理解了；
　　46.记录下在和别人交流时发现的自己忽视或不理解的知识点；
　　47.请不断的对自己写的程序提出更高的要求,哪怕你的程序版本号会变成Version 100.XX；
　　48.保存好你写过的所有的程序——那是你最好的积累之一；
　　49.请不要做浮躁的人；
　面向对象和generic programing
我这段时间突然发现
c++最有意思与最前言的
不是oo
是oo与generic programing的合作
generic programing解决了效率问题
迭代器的抽象化，使c++摆脱了oo带来
的复杂性与动态绑定带来的额外开销
达到了手工c的效率

oo的思想，可以退出较低沉的界面
集中与结构类型的抽象化。

纯oo的c++已经落后，
完全可以用oo建立结构，
generic programing解决效率问题

用这种合作的方法，
1，重写c为底层代码的unix
2,重写各种综合性的库
3，彻底改造现有的大型项目 如mysql
用这种方法，以现在的进度，写一个
高于现有数据库思想的先进数据库
是最合适的，
C++的表面困境来自两方面，一是开发效率低，而是容易犯错，维护难度大。此二者俱是表象，本质就是一个——过度复杂。或有人说C++之关键缺陷是没有统一完整的类库支撑，Bjarne Stroustrup即强调此因素。然而这其实只不过是一个结果，而不是原因。正是因为语言太复杂，才无法在有效期内开发出高质量的大一统的类库。
C++的复杂，并非是其体积庞大之必然结果。复杂是对结构混乱无序程度的描述，规模大，结构不见得必然复杂。

C++的复杂，也并不是如很多人所认为，是若干种编程范式（paradigms）的并存而至。事实上，现代实用编程语言至少有2-3种范式才能登大雅之堂。以范式数量论，Python和Ruby等新型动态语言的范式甚至多于C++，然而它们却以简单和开发效率高著称。

C++复杂的根源在于三大约束：与C的完全兼容、静态类型检查、最高性能。在三大约束下，C++未能完善对于面向对象思想的支持，未能建立强大的动态能力，从而使得C++在OO这个单项上存在本质缺陷。事实上，C++的过程、OB模型相当成熟和稳定，而泛型模型，就单项来说，除了语法丑陋之外也没有大的问题。缺陷集中体现在OO模型的实现，并因此干扰了其他几个范式的完整程度。然而，OO的缺陷绝非设计者的偏执，其原因在于三大约束。如果坚持三大约束，则即使再重新设计一次，结果也与今日相差不远。Stroustrup在多种场合表示，对C++的设计没有大的后悔之处，意思就是这个。侯捷先生早在2001年初即对我说，C++在OO上不及Java，当时体会不深，认为没有大一统的单根类库会使设计更加灵活，后来又认为凭借GP可以抵消OO的不足甚至超越之，现在看来即使不是不可能，这条道路也必然是艰辛异常，成败难以预料。

又因为上述所有因素的综合作用，C++基础类库的建设只能进行到很低的高度上就停下来，因为再往上走就面临重重困境和无穷无尽的争论。C++标准库实际上是一个距离应用相当遥远的非常基础的程序库，其主体部分只相当于Java中System和Util两个package。而C++宁可停在这样的低层次，也不愿意放弃三大约束中的任何一个。这种执着使得高层标准库设施的建立异常困难，使用也不容易。Boost库中相当部分组件的易用性不佳。

模板的复杂语法与三大约束也有直接的关系。另一个原因是Bjarne在发明模板时目标单纯。C#和Java加入泛型机制的时候，没有继承C++最好的经验，却不约而同地继承了C++模板机制中最坏的部分——语法，短期来看，丧失了一次改革的良机。长远来看，必成累赘。

不完善的异常机制则是在木已成舟的情况下迫不得已的设计。

C++中的多种范式并行，是一些最复杂问题的表面原因。以至于Doug Lea建议在一个项目里只坚持一个范式。但是这仍然只是表象。归根结底还是因为OO的缺陷，使得与其它范式合作时困难成倍放大。故自接受Doug Lea思想以来，我的C++（乃至其他现代语言，尤其是Python等多范式语言）的开发设计思路是：

1. 首先选定一种思维方式（即范式），尽可能只用这一种思维方式解决问题；
2. 如果在局部遇到其他思维方式更得力的问题，则经慎重考虑后，可以将另一种风格包装在局部，解决局部问题。但整个系统在某一层次之上看来，应当是统一一致的。一般C++的开发，应以OB为基本风格。除非有类似MFC那样庞大而成熟的OO库支持，不应贸然在整体上使用OO风格。
3. 多种风格混用，除非有已被充分讨论并验证的方案（即成熟模式），可提供单一风格不能提供的较大优势，否则应极力避免。当然鼓励在研究中探索，但实践是另一回事。

C++完全可以在90年左右摆脱C的约束，随后简化模板语法，完善异常模型，接纳可选GC，建立完整的单根类库，付出性能小幅度下降的代价之后，实现语言整体升级。

但是C++选择了另一条路，三大约束坚持到底，坚守系统层面，以替代C为己任。是福是祸，实难判别。如果90年代初选择升级，胜则扼死Java于摇篮之中，败则寸土不保。不过以C++之高性能，胜面应稍大。如今看来，在系统面彻底取代C已无可能。

1994年为STL拖延标准立案时间长达四年，如今来看功过亦存争议。错过黄金时机不说，STL典范一立，库设计风气为之一改。然而在解决应用问题上，泛型较之OO，适应能力远逊之，且应用困难。

总之，C++的三大约束，既是其兴起之要素，也是其衰落之源头，同时，又是其今天得以屹立不倒的重要基石。其是非功过，实难一言以蔽之。

补充：2004年10月20日
C++/CLI之对于C++的意义，其实并不在于使C++重新获得了制胜Java或者C#的机会，而在于巩固了C++作为.NET平台上系统语言的地位。由此知，C++/CLI的发展，的确如Stan Lippman所说，是C++一贯发展思路的延续。三大约束固然已经放弃，但其精神实质仍在，形攻而实守，未来将可作为.NET上唯一最强之系统语言而长命百岁。

C++/CLI决不简单，但在大多数时候，它能够比传统的C++表现的简单些。这就是Andrew Koenig说的，通过复杂实现简单。

C#和Java的繁荣期，则有赖于人们对于大一统的中层次语言的信仰有多坚持。此两种语言无论在系统开发还是在应用开发中都非最优选。目前C#出现一些迹象，引入一些动态语言特性如cmdlet，又强化系统编程能力，想上下通吃。这是一条不归路，必会使C#变得更加复杂怪异。

学习编程语言，通语法能实践，不过十分之一。真正重要的是掌握其多种多样的实用的idioms或模式。这些模式才是体现了语言精神的东西。未掌握各种语言中的主要应用模式，则应羞于用“会”字。常听有人说某某语言一周乃至一两天即可掌握，这个掌握的层次肯定是很低的。真正要“掌握”语言，则我等凡人，诸事缠身，非得集中精力学习实践一两年，将该语言所擅长领域的应用问题熟悉过一遍，才有可能。若论精通，则十年也不容易。Henry Spencer用了30年C，仍乐此不疲；Pragmatic Programmer中评价Ruby说，学上四个小时就可以用它解决实际问题，但是10年之后还为它层出不穷的新意感到惊讶。偶见有人举出自己“精通和掌握”的工具和语言，动辄长达八九上十种，实为笑柄。真正掌握一种，已经是难能可贵，熟练掌握两种层次不同，思维不同的语言，应是有抱负的程序员的自我要求。何况如今之软件开发涉猎甚广，仅通编程层次还显不够。不过总之百招会不如一招精，做什么工作都要有自己的过人之处。