猶如<<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分鐘。