@Alleluja
說得好，說得好。兄臺有blog沒，咱也加一個。:)
oop老前輩可差遠了。我也就是稍微早一些學C++時學了OOP。我心目中更完善的C++應該是有class，但沒有oop。呵呵，有點胡說了。我是指動多態。它的功能用runtime concept代替。我希望的是C with GP，包括static的和dynamic的。

@AlexEric
說對了，concept就是模板的發展方向，看C++09。
說道人如何取舍，對于多數程序員而言，取舍的東西太多，影響他們的發揮。這也是C++發展concept的原因之一。

@Computer Worker
舍棄vtable很容易，但如果我還希望同時獲得高級抽象能力呢？

@陳梓瀚(vczh):
的確如此。只是在vtable下，即便沒有指針也無法非侵入地處理對象。但pod可以。C+gp同樣可以在模型上建立serialization架構，但副作用相比oop更小。兩害相權取其輕啊。

@Michael Li：
這些想法原本也就是沿著C++未來發展路線的進一步“遐想”。C++09走出了static concept這一步，并且正在以庫的方式模擬runtime concept，那么更進一步便是語言級別的runtime concept了。我只是想看看如果C++擁有語言級別runtime concept，可以獲得什么樣的結果。

@oldrev
這個就沒辦法了。這些接口都是需求設計驅使的，只是不同的手段實現而已。這方面的問題由于沒有廣泛的應用，還不太清楚，需要實踐檢驗。
concept相比interface的直接好處在于兩點：1、不需要在接口實現類型產生前定義concept，任何時候都可以，這樣可以減少設計上的壓力。這是非侵入的好處。2、concept驅動下的模板在runtime和compiletime是相同的，也就是同一個模板可以同時用于runtime和static，而不需要另搞一套。
間接的好處是會對語言整個模型產生根本性的影響，從而消除語言某些方面的復雜性和缺陷。這個我打算在下一篇blog里探討。

to oldrev兄:
我不太理解“只為約束函數參數而沒其他作用的 concepts”這個概念，能否給個例子。這個問題我這么想：concept以及runtime concept同oop的interface的差異我以前的blog和toplanguage討論中都談論過。本質上，interface是“用一個類型來表征一組類型”，邏輯上就不那么和諧。而concept則是用一個獨立的，專門用于描述一組類型的概念實現這個功能。interface的弊端，比如侵入的接口、造成類型耦合等等，在concept中不會存在。運用concept，我們可以消除這部分問題。至于其他的interface問題，可能來自于需求和設計，通常也無法全部通過這種技術手段消除。
當然就像clear兄所說，concept可以auto（需要在定義concept指定auto），這也消除了不少麻煩。只是auto需要謹慎，只有那些含有公共語義約定的concept，比如swappable、copyable等等，以及形式（成員）非常特殊，不可能有其他語義的類型與之混淆的情況下，才可以使用，否則容易引起混亂。

btw：如何才能把鏈接的樣式改成標準樣式？我寫的時候都是藍色帶下劃線的，但是發出來就不見了。

to duguguiyu:
如果沒有concept當然可以，但是必須有一種完成concept功能，也就是類型特征描述的機制，實現模板（泛型）的類型參數約束，以及提供優化線索的功能。
關于編譯器，靜態concept是未來C++09標準的一部分預計明年可以出臺。據我所知，現在只有一個試驗性編譯器支持concept：conceptGCC，http://www.generic-programming.org/software/ConceptGCC/。
而runtime concept，八字還沒一撇。Bjarne有一篇論文，可能在今年三月份發表，提到了runtime concept。但沒有涉及語言層面的實現，而是庫方面的實現。相關這些內容的其他文獻，可以看我前一篇文章《OOP的黃昏》后面給出的參考。

to TeirDal:
其實，“每個類型都是類”和“每個類都是類型”是等價的，只要語言不再區分內置類型和用戶定義類型這兩種概念。隨著操作符重載的出現，我們有能力使得用戶定義類型同內置類型具有相同的特性。
貨幣是我能找到的最簡單的案例，目的當然不會是創建一個貨幣系統。主要是為了展示C++的gp和tmp的運用。以及強類型約束對于構建穩固、便捷的系統
隱式轉換是利用=操作符實現轉換/賦值操作。它有一個好處就是：同一個語義，同一種形式。這種抽象的表達形式更貼近于現實業務。由于它在邏輯上的抽象性，那么對軟件的修改更加有利。比如：
//成員函數
USD u=20;
RMB r;
r=u->toUSD();
//隱式轉換
USD u=20;
RMB r;
r=u;
如果r的類型變成JPN，那么只需修改r的類型即可，而無需做更多的改動。
//成員函數
USD u=20;
JPN r;
r=u->toJPN();
//隱式轉換
USD u=20;
JPN r;
r=u;
此外，多個香爐多個鬼，顯式的轉換函數可能寫錯，會引發很多不必要的麻煩。
實際上，使用成員函數的方案的工作量比我給出的方案來的大很多。因為如果有n個貨幣，那么每個貨幣類都必須有n-1個轉換函數。所有轉換成員函數的總數將達到n*(n-1)。這是組合爆炸，也正是我的方案所要解決的問題。
如果你真要用顯式的轉換函數，那么也應該用成員函數模板：to<>()。這樣可以利用我在這里使用的元編程技巧把轉換函數的個數變成n。
但在運用了operator=()操作符模板后，只需要一個轉換函數即可。也就是說，這里的方案把原本n*(n-1)的代碼量變成了1。你說實現起來哪個更長？:)
python的思想，我不能說他錯，但用在這里并不合適，因為python的應用領域在于高層的應用開發，而這里所探討的問題則是基礎級別的軟件設計。python并不能應付這里所面臨的問題。
這個貨幣系統的真正的問題是，它是靜態的，而在現實軟件中，貨幣必須是動態的，也就是說我在編程的時候，并不知道我要把那兩種貨幣相加或者賦值。這樣，這個類型系統也就失去作用了。

non member non friend這一點上，Sutter的案例有些極端。但他的思想代表了整個C++社群，或者說現代multiple-pariadm風格的主流。而meyes的文章則更加理論化。
這種函數的分離帶來兩個好處：首先，就是靈活性。無論如何成員函數的靈活性無法同自由函數相比。我們無法得到一致性的論斷，自由函數絕對好，但是可以明確自由函數更靈活，更易于替換，特別是有能力在維持原有的訪問形式之下，擴種針對一個類的操作，這是成員函數無法做到的。
另一個方面，自由函數更利于泛化，構造通用的算法或算法框架，提高整個設計的擴展性。
使用自有函數基本上沒有什么副作用，但成員函數由于被強行綁定在類上，無法自由變換。

如果這樣分的話，還應該有第四種特化：
template<typename T1, typename T2>
class X {...};

template<typename T>
class X<T, int> {...};
以及2、3、4的混合
template<typename T>
class X<T, T*> {...}
template<typename T>
class X<vector<T>, T&> {...};
...
更極端的，這樣的特化是否該歸為第5類呢：
template<typename T>
class Y;
template<typename R, typename P1, typename P2>
class Y<R (P1, P2)> {...};//針對帶兩個參數，有返回值的函數類型特化

實際上，3僅僅是局部特化結合template-template parameter的一個應用。算不上一“種”特化。
總的來說，還是C++標準中的分類更加清晰。

另外，根據C++標準術語，應該是“類模板”（class template），而不是“模板類”。一般認為，“模板類”是模板實例化（特化）后的類：
vector<int>

現在對concept有什么正式的譯法嗎？

stl的核心，也就是平臺軟件的核心，就是“可擴展”。
平臺軟件通常很難遍歷所有的需求，于是抽象出業務模型框架就顯得尤為重要。一旦抽象出業務框架，則可以通過插入和替換組件的方式實現擴展，將軟件定制的開發量減到最小。

模板帶來的是強類型的多態（利用靜多態）。它的好處就是利用強類型在編譯時攔截大量的錯誤。同時，類的出現，使得操作成為類型的一部分。強類型化后，不僅僅數據結構的邏輯性得到檢驗，連施加在這些數據上的操作也得到約束。因此，合理地運用模板和隨之帶來的強類型多態，可以使得代碼更高效，更簡潔，也更安全。
由于業界的大多數程序員還在努力消化OOP帶來的技術革命，還無法理解gp帶來的優勢。不同于OOP，業界也還沒有出現GP方面完整的理論，所以對模板及其帶來的好處還未能充分理解。