犹如<<Ghost in the shell>>中的素子那样,最近某天早上醒来后,“我的灵魂正对我低语”--C++中的某个部分似乎有些不对劲!(嗯,<<The Matrix 2>>中的neo在最后关头也说过类似的话)

... ... (经过一番思索)

我看过<<范型编程与STL>>、<<Moden C++ Design>>这类偏重于template的运用,较长一段时间对template的体验后,我忏悔:由于在class之前写了太多的template<...>,以至于有太多的时间在等待compiler的努力工作,花了过多的时间去分析模板参数推演失败后的“壮观错误信息”,以至于不得不对含有template关键字的code小心万分,我知道,不这么做的话,一不小心就会云里雾里。

一般情况下,我们需要模板实现的值类型是必要的,容器类型用STL的基本上够用了,而使用了大量template技巧的boost\Loki\GIL\......我希望我应用端的code只需在完成一次于库编译连接后,不再影响其它的编译单元的code,即,只在.cpp\.cxx文件中含入有巨量template的库之*.h,以至于另一个依赖于此单元的编译单元在#include路径上不再无意的重复引入无关的模板库文件。

总之一句话,我曾经把template使用过头。现在正是reload的时候。

所以得到以下一些C++设计原则:
a. 能不用高级特性就不用高级的,其实无所谓过程式编程与OOP和范型编程的高低之分,好比是数学中的加减乘除。尽可能抑制使用template的冲动
b. 象Loki中的Policy-Based design是非常高级,以至于出现template<template<...> class X, ...>的code,导致编译时过长,由于模板天生就是内联语义,一个优化的compiler即使在开启mix size选项时,还是有太多的展开代码,所以编译时长长,程序大大。还是在确实存在设计时就可预见的概念互补,可替换时使用template带Policy-Based design。
c. 对于Template Meta Programming和Loki中使用TypeList做编译时产生继承体系的方法,个人觉得用于程序优化很好,其实它们可以用不少现存的替换方案解决的,不过要学习些新东西,比如:ML,一些与c++内嵌脚本语言,还有专门的指令优化(MMX,SSE),还可以自制一个代码生成器,或是一些预计算技术。
d. 一个不成熟的观点,当用template时想想真的需要这么做吗?回答为否。好,我该去休息10分钟。