C++ 的缺点
C++ 现在最时髦的用法是 template meta programming。booster 们对此非常津津乐道，我本人也是个狂热的booster。到了什么程度？不使用template 就浑身不舒服，不boost一下就感觉对不起C++。但是这种狂热带来的严重后果就是程序编译速度极慢无比，生成的执行程序尺寸超常。
曾经一个 C++ 服务器程序，代码也就10000行左右，编译出来的执行程序竟然20M！编译时间半小时！写的时候感觉不到用了多少template，但是写出来竟然得到这样的结果，不得不让人吃惊！
记得在大学的时候（2000年前后），初学习 template 时，感觉template之间的耦合有点“过于松散”，就像只要有一个螺母，再一个螺栓，就可以往一起套，而不管他们是否一个是塑料，一个是金属，大小粗细是否匹配，螺距是否匹配，所有的这一切，如果只有哪怕一点点不匹配，都会在编译错误中造成一个非常令人费解的超长消息。当初也不知道这一点早已被无数人诟病了，就写了一片文章，自作聪明地提出应该对模板参数有个类似接口声明一样的规格定义（现在C++0x 中的对应物是concept）。当初立即招致骂声一片。现在这一点已经毋庸置疑了，C++0x出世后我们就可以结束这些痛苦了。
但是，前面说的C++的那两个致命缺点，看来短期内很难克服。
编译时间，受制于文件包含这种古老的内存不够用的时代的无奈选择，就像人的阑尾，喉头，视网膜。
程序尺寸，这个缺陷在某些时候也非常致命，举个简单例子，std::sort 使用了多种排序策略，每个sort 的机器码都很大。同时，对每一种数据类型，每一种randiter每一种comparator，都会生成一个sort 的版本，这会造成非常大的代码膨胀。相比之下，C 的 qsort 就没有这种缺陷。如果我们对几十种数据，使用几十个comparator排序，std::sort 的代码尺寸比 qsort 要大几十倍。虽然它在inline方面获得了优势，但是cpucache的失效，甚至是memcache的失效，造成的性能损失要大得多。BS在TCPL中提到的消除代码膨胀的方法，在某些情况下的确有用，但是太繁琐，大约也只有库编写者会使用它。
Java现在也支持泛型，据说不存在代码膨胀问题，但它的泛型只是语法糖，对程序性能好像没有提升。
C++ 怎样平衡代码膨胀和代码性能？是否可以为 template 生成 runtime meta info，用来操纵泛型算法。或甚至使用这些meta info 来在运行时生成真正的机器码。这样甚至可以允许在运行时进行template组装，而不是完全在编译时？这又有些类似于现代虚拟机（如Java HotSpot 虚拟机）的动态优化。
扯太远了，休息下。