我漏掉了pongba兄最关键的要点

27 views
Skip to first unread message

莫华枫

unread,
Nov 29, 2007, 8:15:18 PM11/29/07
to TopLanguage
在帖子"C++的抽象惩罚中,有多少是因为强调性能引发的"里,pongba兄给出了这样的代码:
vector<Plugable> v;
当时我满脑子unbound性能问题,没有注意到这里重要的一个含义:用concept"实例化"一个模板。
用一个具体类型实例化一个模板必然可以实行static unbound多态,即c++传统模板的用法,得到一个类。
但是,如果用concept"实例化"一个模板,那么得到的还是一个...嗯...模板,对吧。也就是说,这里是无法实行static unbound多态的了。必须用runtime unbound。而"实例化"所用的concept则起到type check的作用。
这样,static和runtime unbound都拥有相同的形式,编译器可以根据程序员给出的代码(用什么实例化,类型还是concept),确定所使用的unbound类型。从而使得抽象至少在形式上更加完美。

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

Atry

unread,
Nov 30, 2007, 12:15:37 AM11/30/07
to pon...@googlegroups.com
我就想知道这样的话,这个数组每个元素有多大?或者是每个元素不一样大?还是用指针?
如果用指针的话(类似 boost 的 ptr_vector),那估计还是得用函数指针、虚函数之类的办法来实现。

在07-11-30,莫华枫 < longsh...@gmail.com> 写道:

莫华枫

unread,
Nov 30, 2007, 12:20:23 AM11/30/07
to pon...@googlegroups.com
啊,这只是个理想,或者说愿望,或者说更好的形式。具体的实现还没有考虑呢。
实现的话这些方法都行,具体得看哪种更适用。代价更小。

pongba

unread,
Nov 30, 2007, 12:25:05 AM11/30/07
to pon...@googlegroups.com
On Nov 30, 2007 1:15 PM, Atry <pop....@gmail.com> wrote:
我就想知道这样的话,这个数组每个元素有多大?或者是每个元素不一样大?还是用指针?
如果用指针的话(类似 boost 的 ptr_vector),那估计还是得用函数指针、虚函数之类的办法来实现。
恩,一样大,指针。用类似虚函数表的机制实现。concept其实是可以这样实现的。 不过因为C++并非仅有引用语义,还有值语义,这就比较麻烦:
P p;
v.push(p);
v里面显然不能存到p的直接或间接引用。

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

Atry

unread,
Nov 30, 2007, 12:54:43 AM11/30/07
to pon...@googlegroups.com
如果存指针的话,这个理想的东西和 vector + 虚函数 相比不见得有什么好处,还损失了透明性。
如果是不定长的话, C++ 已经有了, boost::fusion 就是。缺点是语法比较晦涩。

在07-11-30,pongba < pon...@gmail.com> 写道:

pongba

unread,
Nov 30, 2007, 1:04:10 AM11/30/07
to pon...@googlegroups.com
fusion那是静态的。
接口那是侵入的。

莫华枫

unread,
Nov 30, 2007, 1:27:42 AM11/30/07
to pon...@googlegroups.com
vector+虚函数,也就是传统的动多态,在静态类型系统的作用下,要求将一组不同的类型归一化。于是,便有了抽象接口。相关的类型从抽象接口继承,这本身就是死的,缺乏灵活性的。但这种concept化的runtime unbound则具备极大的灵活性。比如:
vector<Plugable> v;  //Plugable是concept,要求类型具备plug成员函数
class myplug
{
    void plug();
}
class yourplug
{
    void plug();
}
class noplug
{};  //没有plug函数
myplug p1;
yourplug p2;
noplug p3;
v.push(p1);
v.push(p2);
v.push(p3); //错误,noplug不符合Plugable
形式上,这更加简洁自然。类型安全也得到保证。更重要的,对于一个你心仪已久,但却不是你开发的类型(无法修改),在传统动多态的情况下是无法直接使用的,除非用adapter。从抽象接口继承而来的adapter,只会是问题更复杂,不是吗?:)

Atry

unread,
Nov 30, 2007, 2:31:08 AM11/30/07
to pon...@googlegroups.com
这个技术的关键在于语言必须支持自动包装一个没有实现接口的类产生二进制接口。如果用库实现,需要有编译时枚举一个接口的成员函数的方法。
如果 D 支持 interface 上的 tupleof ,那么就可以实现非侵入的接口了。

在07-11-30,莫华枫 < longsh...@gmail.com> 写道:

莫华枫

unread,
Nov 30, 2007, 2:48:46 AM11/30/07
to pon...@googlegroups.com
关键是我们需要的是first-class的抽象。通过各类trick模拟某些本该first-class的特性,本身就是c++该受批评的地方(批评者中D算是积极分子吧,所以我说d没吸取c++的教训来着:))。
根本性地解决问题,还需要二进制级别的concept。这才是first-class的特性。更重要的是,first-class特性是多功能的。二进制concept还对泛型的二进制化有关键性的作用。而语言层面的concept本身就是强大无比的,再加上二进制concept,就能够把语言的抽象提升到一个前所未有的高度。
作为语言的进化,我们不应该抛弃一个c++,却又搞出另一个c++来,对吧。:P
我认为应当高出一个c++那样强大的ruby来,这才是大家的心愿吧。:)

Atry

unread,
Nov 30, 2007, 3:23:16 AM11/30/07
to pon...@googlegroups.com
搞不懂,一会儿叫嚣着 DSL ,一会儿又说需要 first-class ……
我个人不在乎是不是 first-class ,但是我在乎晦涩的语法,如果不是 first-class 也能做得很好用,我也很高兴。


在07-11-30,莫华枫 < longsh...@gmail.com> 写道:

莫华枫

unread,
Nov 30, 2007, 3:31:28 AM11/30/07
to pon...@googlegroups.com
first-class的东西就是为了避免晦涩的语法。比如,在没有concept的情况下,做sataic-dispatch很麻烦,必须为每一个类做一个traits类。但有了concept,加上特化规则,就可以很方便地定义各种不同的版本。
至于dsl,呵呵,我的确叫嚣过。可我还叫嚣过"今后不大可能一种语言包打天下"、"dsl做业务层面的开发,系统语言做基础层面的开发"等等。这些言论与first-class没有什么矛盾之处啊。:)

Atry

unread,
Nov 30, 2007, 4:47:07 AM11/30/07
to pon...@googlegroups.com
我和你的想法不太一样。我还是觉得没有 first-class 一样可以做得很顺手。
就 BOOST_FOREACH 也挺好用。如果有 lambda 的话,就用 std::for_each 我看也很简单。我其实根本不在乎语言本身支持很多牛叉特性嘛。

在07-11-30,莫华枫 < longsh...@gmail.com> 写道:

Atry

unread,
Nov 30, 2007, 4:50:58 AM11/30/07
to pon...@googlegroups.com
比如说 D 里面支持 scope(exit) ,其实有了 lambda ,自己用 RAII 来实现一个 scope_exit ,语法也很简单啊。
所以我之前说 lambda 比 concept 重要一百倍。我不用 concept ,做什么都可以直截了当来做,但是没有 lambda ,做什么都得绕圈。

在07-11-30, Atry <pop....@gmail.com> 写道:

Atry

unread,
Nov 30, 2007, 4:58:53 AM11/30/07
to pon...@googlegroups.com
还有,我一点都不觉得存在"把不同类型的对象放到一个长度可以在运行时改变的容器"的需求。

在07-11-30,Atry <pop....@gmail.com> 写道:
Reply all
Reply to author
Forward
0 new messages