有兴趣的看一下Jaakko Jarvi的这篇paper吧（关于运行时的泛型编程的）

[pongba]

有趣的是，这篇paper刚好极好地说明了为什么接口应该永远消失（为什么接口跟模板应该统一起来——实际上ruby这样新进的语言已经这么做了），取而代以真正first-class的运行时泛型。
已上传到文件区了。http://groups.google.com/group/pongba/web/Runtime+Polymorphic+Generic+Programming.pdf

文章介绍的是如何在C++里面实现运行时的泛型。

--
刘未鹏(pongba)|C++的罗浮宫
http://blog.csdn.net/pongba
TopLanguage
http://groups.google.com/group/pongba

[pongba]

On Dec 5, 2007 8:25 PM, pongba <pon...@gmail.com> wrote:

有趣的是，这篇paper刚好极好地说明了为什么接口应该永远消失（为什么接口跟模板应该统一起来——实际上ruby这样新进的语言已经这么做了），取而代以真正first-class的运行时泛型。
已上传到文件区了。 http://groups.google.com/group/pongba/web/Runtime+Polymorphic+Generic+Programming.pdf

文章介绍的是如何在C++里面实现运行时的泛型。

说实话看着人们在C++里面实现这个，只有一个感觉——作孽啊～但又没有办法，有时候的确需要非侵入的运行时接口，怎么办

[pongba]

忘了说了，这老哥是boost.lambda、boost.tuple、boost.enable_if的实现者。这三个玩意的实现，怎么说呢，。。。戴着脚镣跳舞的典型作品了～～为什么在C++里面非得带着脚镣呢。。。OMG

On Dec 5, 2007 8:25 PM, pongba <pon...@gmail.com > wrote:

[莫华枫]

好啊，正想发帖问这方面资料呢。:)
这两天正在思考这个问题呢。
而且我似乎发现Runtime Unbound实际上可以同Runtime Bound一样性能，只要加上点运行时的concept。整个地就可以让动多态退休了。

--
反者道之动，弱者道之用
m...@seaskysh.com
longsh...@gmail.com
http://blog.csdn.net/longshanks/

[pongba]

On Dec 5, 2007 8:32 PM, 莫华枫 <longsh...@gmail.com> wrote:

好啊，正想发帖问这方面资料呢。:)
这两天正在思考这个问题呢。
而且我似乎发现Runtime Unbound实际上可以同Runtime Bound一样性能，只要加上点运行时的concept。整个地就可以让动多态退休了。

这篇paper说的正是这个，已经实现成Adobe Opensource的一个子库poly了。是面向C++09的。用到ConceptC++

[莫华枫]

可能进标准吗？

[pongba]

On Dec 5, 2007 8:37 PM, 莫华枫 <longsh...@gmail.com> wrote:

可能进标准吗？

我猜有可能会提交给boost吧。 标准是不能指望的。

[莫华枫]

如果由语言实现呢？
语言实现的话可以废弃虚函数，让对象布局最简单。

[pongba]

On Dec 5, 2007 8:45 PM, 莫华枫 <longsh...@gmail.com> wrote:

如果由语言实现呢？
语言实现的话可以废弃虚函数，让对象布局最简单。

C++里面现在已经是动静两种接口明显分野了，要语言支持，除非大改版...

[莫华枫]

等bjarne的新语言了。或许还能有些变化。
唉，历史的负担...:(

[holmescn]

我到更期待D 3.0里能加入这些。

看了莫老大的OOP黄昏，很有感触啊。

可是没有了虚函数，继承也就成了摆设了。那在表达"亲子"关系上，是不是会退步呢？

[莫华枫]

没有虚函数，继承用处还是很大的。主要还是回归到代码重用的作用，is-a的关系还在，只是继承类改变基类行为的方式变了。
虚函数不是一定要去掉，runtime concept可以同虚函数共存。只是对于基础性开发的领域而言，去掉虚函数可以简化对象布局，提高整体性能。至少可以提高对象模型和性能的可预测性。
其它问题还在思考中。...

[李扬]

在07-12-11，莫华枫 <longsh...@gmail.com> 写道：

没有虚函数，继承用处还是很大的。主要还是回归到代码重用的作用，is-a的关系还在，只是继承类改变基类行为的方式变了。

 

 继承是为了被重用。如果把继承来作为重用代码的方式不可避免的会造成在继承树上的紧耦合（从这个观点来说ruby没有继承也可以获得很好因为它只需要mixin，和gp。之所以c系的语言需要继承最主要的原因是它没得契约检查和在强类型检测下实现非继承的多态。）。如果紧紧是为了重用父类代码的功能，那么我会认为也许这里有某些功能可以抽象为自由函数（或者有个策略存在于其中，用更c++的方式看看stl的策略分解方式，呵呵其实stl本质上也是一种策略模式）。

 

 

 

 

 

[莫华枫]

很有道理。最近编码中也尽可能用自由函数。继承用的的确很少。
在这种风格下，继承也只是为了不时之需吧。

[Eli]

其实我觉得接口倒是可以保留, 因为接口有时可以当作一个使用说明, 更何况还有与遗留系统的兼容问题.

On Dec 5, 8:25 pm, pongba <pon...@gmail.com> wrote:
> 有趣的是，这篇paper刚好极好地说明了为什么接口应该永远消失（为什么接口跟模板应该统一起来----实际上ruby这样新进的语言已经这么做了），取而代以真正first-class的运行时泛型。
> 已上传到文件区了。http://groups.google.com/group/pongba/web/Runtime+Polymorphic+Generic...
>
> 文章介绍的是如何在C++里面实现运行时的泛型。
>
> --
> 刘未鹏(pongba)|C++的罗浮宫http://blog.csdn.net/pongba
> TopLanguagehttp://groups.google.com/group/pongba

[莫华枫]

concept起到了抽象接口的作用，而且适应面更广泛。（甚至可以对类型的尺寸作出规约）。

longsh...@gmail.com
http://blog.csdn.net/longshanks/

[Googol Lee]

目前的concept还只是编译期实现吧？所以动态的时候还是需要interface的。

我觉得可以这样：
class SomeClass
{
};

class ISome
{
virtual void func() = 0;
};

concept CSome
{
void func();
};

concept_map(ISome to CSome); // 这东西是这么用么？记不清细节了:p

template<CSome T>
void generic(T arg);

generic<SomeClass>(foo); // 设计时就知道是什么类型的

class OtherDyn : public ISome
{
// 把ISome的接口映射到SomeClass的方法上
SomeClass some_;
};

generic<ISome>(otherDyn); // 运行时才知道会是什么类型的

这样，不是又能统一两者，又只有一套代码么？除了要手动写OtherDyn类把SomeClass映射到ISome接口上去，其余都挺直观的吧？

在 07-12-14，莫华枫<longsh...@gmail.com> 写道：

--
新的理论从少数人的主张到一统天下，并不是因为这个理论说服了别人抛弃旧观点，而是因为一代人的逝去。

My blog: http://googollee.blog.163.com

[莫华枫]

前些日子不是对此好好讨论了一把，不是？:)
而顶楼的这篇文章，则是这方面的非语言实现。

[Eli]

我觉得有时候会需要不同方式的对同一问题的具体手段, 不见得一定是一个涵盖了另一个, 另一个就毫无必要了, 关于Concept这个问题没有仔细琢
磨过, 就不胡说八道了. 在C#中是where T : 接口一, 接口二, 这么和接口统一的, 可惜C#的泛型本身比起模板是太弱了, 除了扩散
到解决方案各处, 是干嘛嘛不行, 而且只有运行时多态.

> --
> 反者道之动，弱者道之用
> m...@seaskysh.com
> longshank...@gmail.comhttp://blog.csdn.net/longshanks/

[Googol Lee]

恩，是。我也是这两天自己试着用了一下，发现确实很好用。

[莫华枫]

这就是今后需要进一步考察的，runtime concept是否有能力在各个方面覆盖传统动多态。如果不是，就应当让他们并存，发挥各自的作用。如果是，那么就可以完全替代，而没有副作用。用runtime concept替代动多态的一个主要动机是简化对象模型。如果对象模型可以回归到没有虚表的状态，那么c++曾经面临的诸多问题，比如dynamic_cast的性能问题、对象布局的统一问题、abi问题等等，都可以得到圆满的解决。这些好处还是很诱人的。关键还是在于runtime concept是否有能力全方位覆盖动多态。
现在看来，原先的一个最主要的障碍——性能，已经不再是问题了。那么余下的就集中在具体的应用场景上了。我初步能想到的一个问题是Template Method。这个模式依赖于虚函数的延迟绑定，去除了动多态，也就废除了虚函数，这个模式便不可实现。但是，考虑到模板的扩展能力，可以使用template+traits/policy这种手法实现template method同等的效果。

On Dec 14, 2007 9:29 PM, Eli <Eli...@gmail.com> wrote:

我觉得有时候会需要不同方式的对同一问题的具体手段, 不见得一定是一个涵盖了另一个, 另一个就毫无必要了, 关于Concept这个问题没有仔细琢
磨过, 就不胡说八道了. 在C#中是where T : 接口一, 接口二, 这么和接口统一的, 可惜C#的泛型本身比起模板是太弱了, 除了扩散
到解决方案各处, 是干嘛嘛不行, 而且只有运行时多态.

On Dec 14, 7:47 pm, "莫华枫" < longshank...@gmail.com> wrote:
> concept起到了抽象接口的作用，而且适应面更广泛。（甚至可以对类型的尺寸作出规约）。
>

> On Dec 14, 2007 7:19 PM, Eli < Eli...@gmail.com> wrote:
>
> > 其实我觉得接口倒是可以保留, 因为接口有时可以当作一个使用说明, 更何况还有与遗留系统的兼容问题.
>
> > On Dec 5, 8:25 pm, pongba <pon...@gmail.com> wrote:
>
> > 有趣的是，这篇paper刚好极好地说明了为什么接口应该永远消失（为什么接口跟模板应该统一起来----实际上ruby这样新进的语言已经这么做了），取而代以真正first-class的运行时泛型。
> > > 已上传到文件区了。
> > http://groups.google.com/group/pongba/web/Runtime+Polymorphic+Generic...
>
> > > 文章介绍的是如何在C++里面实现运行时的泛型。
>
> > > --

> > > 刘未鹏(pongba)|C++的罗浮宫 http://blog.csdn.net/pongba
> > > TopLanguagehttp://groups.google.com/group/pongba
>
> --

> 反者道之动，弱者道之用
> m...@seaskysh.com
> longshank...@gmail .comhttp://blog.csdn.net/longshanks/