大約每隔十年，都會出現一個編程新概念，宣布自己是以往概念的繼承者。我們也再一次相信，從今往后軟件比以前更可靠，更容易build，或者更有意思(沒有人相信它會比以前更小或者更快)。在70年代，有結構編程；在80年代，開始了面向對象編程；從90年代中期，出現了范型編程(generic programming)。范型編程得名于其用模板而使代碼重用的高效技術(范型類和范型函數)。
模板類和模板函數都是非常有用的工具。例如sqr()函數可以計算平方數，任何定義了乘法運算的數據類型（數字，矩陣）都適用。標準容器類(如list)都是模板，這樣對于每個新類型無需重寫了，這正是使用舊版的C++時真正頭疼的事情，因此我認為ISO的標準是個偉大的進步。然而，在這個過程中有些東西用得過頭了。
例如：標準庫中得string 和iostream 都是使用"character traits"類型作為參數。這意味著同一個basic_string<>類可以用于ASCII字符串，也可用于Unicode，甚至用于火星人的三字節字符串（原則雖然如此，但許多版本都只是實現了ASCII字符串，看起來有點滑稽）。標準要求這些常用類必須實現成模板形式，而這些類幾乎涉及到所有C++應用。
但是這對性能和調試會帶來許多麻煩。下面幾個試驗解釋了這個問題（本試驗使用的編譯器為VC++6.0)。編譯器同時支持新風格的iostream（使用模板）和經典風格的iostream, 因此我們能比較他們二者的版本實現。第一個測試程序當然是使用"Hello, Word"了，新風格的編譯時間是經典風格的2倍。另一個更正規的例子大約有200行，每行輸出10個變量用于計數。這個測試程序最顯著的結論是編譯速度：新風格版本花了10秒編譯完成，而舊版本只使用了1.5秒。10秒時間可并不少，可以完成很多事情。另外，新風格版本的可執行文件的大小為115K，而舊版本只有70K。你的測試數據可能有些出入，但是整體結論是一樣的：當使用新版本時，會有更慢的編譯速度和更大的可執行文件。這并不是因為微軟公司編譯器的問題，使用GCC測試也會得到同樣的結論。
當然，和過去不一樣，可執行文件的大小并不是那么重要，現在，可編程設備種類正快速增長，包括許多信息應用，如遙控、手機、智能冰箱、基于藍牙技術的咖啡機等等，在這些應用中內存近幾年都會是十分寶貴的資源。使用標準iostream 而產生的額外的二進制文件，來源于內聯了整個模板類的代碼，要是沒有code bload工具，你很難優化那些重要的操作。對我來說，編譯時間問題更嚴重一些，因為這樣意味著更長的等待，從而失去了開發中非常重要原則：互動原則。
現在我們來考慮調試的問題。標準庫中string 類的模板實現非常聰明，但并不適合于調試。你會面臨使用超長名字的編譯器和調試器的信息：
class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char>>
同樣對于非常有用的容器 map < string,string > , 你可以去想象其復雜性。這些名字太長了，以至于產生數十個內部名字被截斷的警告。對于初學者來說，std::string 應該設計得盡可能透明，而不應該讓他們面臨許多語言內置得一些特性。當輸出了編譯錯誤信息后，在技術上講，應該是可以查找到所有的 typedef 。我在 UnderC 項目中就試圖這么做。Verity Stob 建議編寫一個后置的處理器來翻譯這些錯誤信息，我倒希望這是她這么做只是開個玩笑。如果不使用這么復雜的類型，這個問題就會容易處理的多。我在C++開發上的秘訣就是（我首次坦誠的公開這個秘密): 在稍微大一點的工程中使用一個兼容的string 類來替換std::string 的頭文件. 有時我會重新build 這些標準的頭文件，用來檢測是否我的庫還能正常使用，但讓其他人為如何提高其性能而努力。
當然，在許多應用中我們都需要這種std::string提供的靈活性，例如，需要同時處理ASCII 和Unicode字符串，或者需要定制自己的allocator 等等。但這并不是普遍需求(通常程序員要么只處理ASCII，要么只處理Unicode ), 看起來對于程序員承擔這種范型機制有些不公平。這種機制確實讓標準庫的設計者覺得很有意思，但增加了應用開發程序員使用的復雜度。這似乎顛倒了這個原則：良好的標準庫設計應該隱藏其實現的復雜度，而讓用戶直接使用。但std::string 對其實現的復雜度隱藏得并不夠，導致在用戶使用過程中不斷的遇到設計中的問題。我們不能要求標準庫的用戶都是專家。標準堅持要求這種特定的實現方式，和標準庫的設計初衷相違背，其初衷是只提供公共的接口和包含一些特定功能的類庫。自然，這種范型模板對于那些真正去要他們的人是一直有效的。
這些細節考慮同樣應用于標準容器，例如list<>容器，list 有一些額外的默認模板參數，用于定義了默認的allocator。當然自己定義allocator 十分有用，但絕大多數人不需要自己去實現。這些泛化的版本完全可以作為單獨的模板提供。我承認這樣做會讓標準庫的設計在技術上變得沒有以前有意思，但這些庫在設計之初就應該考慮到最終用戶。篡改一下C++的頌歌：用戶不應該為他們不需要的東西買單。
當我們不需要模板的時候，我們不得不使用模板。除此之外，在C＋＋中用范型編程還會遇到另一個的問題。大多數人都同意，標準的algorithm 十分有用。如果你有一個整型的vector, 你可以直接使用下面的語句來排序：
sort(v.begin(),v.end());
因為int型數據的比較函數時內聯的，而且這種范型算法比舊版本的qsort()函數速度還快，也更容易使用，特別是使用用戶自定義類型的vector. copy()函數也可以在任何時候高效率地拷貝任何數據。
但有些應用理解起來十分晦澀：
copy_if(v.begin(),v.end(),ostream_iterator<int>(cout) bind2nd(greater<int>(),7));
如果要寫得嚴格一點，每個名字都應該加上std::前綴，這里假定所有變量都是使用全局命名空間，或單獨使用命令或用其他方法。用Stroustrup (C++的創始人)的例子更容易說明問題，這個例子把所有的整型數輸出到終端：
vector<int>::iterator li;
for (li = v.begin(); li != v.end(); ++li)
if (*li > 7) cout << *li;
Stroustrup 告訴我們如果使用顯示的循環是"麻煩而又容易產生錯誤", 但我看不出使用第一個版本有什么優勢。顯然，人們能習慣這種方式，人類的適應性很強，作為專業人士，我們也不得不學習這個新概念。但是，這樣做并沒有減少多少麻煩，而且我們可以證明這樣做可讀性更差，更不靈活。同時，它還會限制你的設計。例如，假設我們有一個Shape * 的指針list, 我們可以通過下面的調用方式來畫出他們自己的形狀：
for_each(ls.begin(),ls.end(),
bind2nd(mem_fun(&Shape::draw),canvas));
也可以選擇這種方式：
ShapeList::iterator li;
for (li = ls.begin(); li != ls.end(); ++li)
(*li)->draw(canvas);
現在假設我需要修改我的設計，我只想畫那些滿足某種要求的圖形（而且不希望把這些需求包在shape類里面), 那么我只需要在顯式的循環中增加一條if條件語句。如果要使用范型概念，我唯一能想到的方式定義一個函數，然后使用for_each()算法。使用設計模式一書中的術語，第一個例子是一個內部迭代器(internal iterator)，第二個例子式一個外部跌倒器(external iterator). 作者認為C++ 并不擅長使用內部迭代器，我想我們還是應該考慮語言的局限性。其實問題在于在C++中過度應用范型概念--從而導致不必要的難度。C++ 完全不支持一般的匿名函數(anonymous functions)如LIST, SmallTalk, Ruby等。C++中的匿名函數或許看起來和下面一樣，可能某天有人會實現它：
for_each(ls.begin(),ls.end(),
void lambda(Shape *p) { p->draw(canvas); });
C++ 是一種不可思議的編程語言，小到手機，大到跨國際網絡，都有其應用。它非常靈活，能夠支持多種編程風格，但這種靈活同樣也是其問題所在。編程的藝術在于為特定的問題選擇合適編程風格，就像老師總提醒寫作文是要選擇好的風格一樣。我并不想詆毀 C++ 標準庫，這里面包含了許多人的辛勤勞動，并為大家提供了一個公共平臺。我對于這個標準的態度是，它和范型編程聯系過于緊密，從而變成了在說明什么風格是好的編程風格(例如，算法中明顯傾向于不要使用顯式循環), 同時它也讓程序員們不得不介入一些實現細節(如basic_string<>)，這樣做讓人們更加覺得C++ 是只是內核工程師們的編程語言。