犹如<<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分钟。