longshanks

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方面完整的理论，所以对模板及其带来的好处还未能充分理解。