longshanks

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