神话与谬误：争论C++前你应当知道什么

　　这其实跟C++的“教义”没有关系。C++如果有教义的话也是实用为上。这种现状是自发产生的，它的动力来源于人的心理。如果Java语言有各种各样的特性组合，且这些特性组合能够某些时候满足开发中的实际需求的话，也是一样会出现这样的情况的(事实上一个小小的Java Closure就已经引起了大量口水了)。某种程度上，LISP里面用函数来实现自然数系统，也是一样的道理，你敢说，你第一次看到它的时候，不惊叹?人之常情而已。 那这种哲学对不对?废话。当然不对。不但不对，而且有害。很多C++日常开发者在学习库开发技巧上浪费了很多时间，掌握了根本用不到的技术，而且这些技术，不如称为技巧，可能还会随着语言进化变得根本无用武之地。还不如好好学学如何让自己的代码更KISS呢，基本的编码准则要远远重要得多，正如我刚才说的，日常开发，一本《The C++ Programming Languag》加一本《C++ Coding Standard》足够了。

　　另外，说到语言进化顺便说一句，语言进化的职责之一便是废黜繁复的技巧，取代以直接表达思想的语言特性。而C++0x真正在履行这一职责。 最后来说一说前面留下来的一个问题：为什么C++设计的初衷——“不要固执于完美”——某种程度上带来了这个局面呢?

　　因为正是因为这种理念的指导，有不少语言特性从理论上都是不完备的：比如有copy语意没有move语意(有左值引用没有右值引用)，于是Alexandrescu用Mojo框架来解决;比如支持可变参数的函数调用却不支持可变参数的模板参数列表，导致用元编程来解决;比如不支持构造函数转发，导致必须factor出一个公共的initialize函数来;比如不支持强类型的enum，结果用一大堆宏结合类来解决;比如不支持initializer list，结果用复杂的模板技术来实现某种类似的初始化方式;比如不支持auto和typeof，结果用更复杂N倍的模板元编程技术来实现一个模拟;比如不支持内建的alignment指示，导致Alexandrescu在实现类型安全的union的时候用尽了模板元编程技巧;比如不支持内建的foreach，结果借助于诡异的语言角落实现了一个几近完美的模拟;比如不支持内建的concept，导致使用模板技巧来实现也算能用的concept检查…这个列表可以一再延长下去，C++中这样的示例太多了。C++的不完美导致了各种各样的技巧应运而生，哦，不，应该说，应实际需求而生。这从另一个侧面正说明了一点—— C++太需要进化了!