为什么会冻结啊~

???

这次我们问Stroustrup对loki的看法，你猜猜是什么？
he's just too clever ...

我一时心血来潮更改了注册的邮箱地址，然后CSDN试图将新密码发到新邮箱，然后新邮箱好像不灵光，然后我收不到新密码，然后我不能登陆CSDN。大家有没有觉得这个更改邮箱的事务设计得不够健壮。

Stroustrup 到底是夸他呢还是贬他呢？

感谢mr_oydy。

我在杭州和Stroustrup闲谈时，提及Andrei（我主要是对typeof好奇，提了一些Andrei的Paper作为我的反对证据），结果Bjarne就说：Don't think Andrei's stuff simply， it's too brittle……（大意如此），然后我也不是很清楚他到底想表达什么意思——当时我太激动了，而且吃饭时很多话也听得不是很清楚：（

单纯从技术上考虑，loki的确有些好高骛远，但是我觉得loki后蕴藏的是一种新的方法，Andrei只是选择了C++作为其实现工具。也许C++并不是一种理想的工具，这也并不能成为评价这一方法成功与否的依据。

哪里可以找到《Modern C++ Design》的电子版？？？

Bjarne的下一句就告诉你什么意思了，
he just wants to proof himself
他认为mcd属于过度使用template的，跟过度使用继承一样不好

老大，能把你和Stroustrup的 所有经历整理一下
我们看看咯
谢谢啦

为什么要这样说呢？好大一盆冷水呦。当我们一遍又一遍地写下相似的查找算法时，会意识到需要一个模板把这个算法抽象出来。同样地，当我们一遍又一遍地运用抽象工厂模式时，会意识到需要一个模板把这个模式抽象出来。这有什么不对的地方吗？我所能想到的唯一缺点是当模式唾手可得时，人们很可能会把它随意地用到不恰当的地方。要不然就是loki的抽象工作做得不够好？还是模式在本质上无法被抽象的？

模式真的可以被独立地抽取出来吗？
一般来说，模式不会是单个出现的，不同的模式同时出现会有不同的组合，你能够用一个抽象就搞定他们吗

你的意思是模式只能被包容在一个框架（比如MFC,ACE）中？说句实话，我对模式一无所知，根本无法抵挡Stroustrup这样有力量的人物的置评。 babysloth一定要对你的言论负责呀，我可就信你了。

我可不负责，我只负责转述
myan和我会把这次整个过程记录下来，很宝贵的采访。
问他这个问题（模板是否被过度使用了）之前，我是很希望他说yes，但估计他会说no，没想到他极干脆地说yes。我一直不赞同mcd里描述dp的方式，毕竟dp粒度太大。这是我个人的感觉，你想想，连SINGLETON这么简单一个模式都无法写成类（已有的实现或多或少都有问题），还能期望更多吗？像cber说的(其实是GoF说的)，模式之间的组合更是千变万化，很难描述。我个人更希望多积累实际编程经验，与dp相互印证，也就是说，我更把dp看成是经验的总结，形而下，而不是形而上那些玄妙的东西。我是程序员，不是哲学家。

我希望大家能够赏光看看我写的《工作感想》那篇帖子。老实说，每当有人雄心勃勃的提出“重用”的理论时，我们都应该慎重再慎重。很多时候，表层看似容易的重用，往往需要优秀的底层工具。而底层工具的出现，需要创造力，有时也需要运气。

如果有人当年希望摆弄“宏”来完成算法重用，注定要失败。只有先潜心完成template的设计，算法重用才能成功。同样，今天的人们仅仅摆弄template就能完成pattern的重用吗？我是非常怀疑的。计算机仍然还处于摸索基础理论、探索基础工具的年代，对大师的崇拜是必须审慎的。

to middle：
对于重用，我曾经在myan的文章里面有过一段“呓语”，你可以去看看
我记得好像是在《C++风格杂思录》中

同意middle兄的看法。
C++ templates 根本上就是一可参数化类型实现手段。脱离这一根本，利用templates搞编译期计算的做法就是overuse了。当然，这不是说编译期计算是无意义的（相反，它的意义非常大），只不过目前的C++ templates 并不支持这样的做法。不知道以后新版C++会不会在这方面有大的步伐。但估计近期内是不会有的 (真正的大的变化至少要搞到5-10年之后才能见到?)。另外一个是要注意overuse和abuse(滥用)区别, abuse是肯定有害的。overuse就不一定了。

Andrei对C++的贡献是很大的，Andrei可以说是当代最富有创造力的两个C++程序员之一。对Andrei的贡献, 非常同意anrxhzh(百宝箱) 兄的看法: loki其实真正展示给我们的是一种思想 (他那本书才是真正的"C++编程思想")　－　概括地说，什么编译期计算我们可以做，如何做，和这么做的意义，等等　－　通过Loki非常具体地展示出来. 

mcd核心思想并非所谓分离编译期计算和运行期计算，请注意这本书的副标题
generic programming and design patterns applied
他是希望将template用于实现模式，然而根本不为C++社群所接受
bs的反对是一个例子，标准委员会发起的boost两次拒绝loki加入又是一例，
andrei本人也非常无奈，可以说，这不是未来的方向。andrei本人计划的新书名叫The Return of C++，不知道会不会有所改变呢，呵呵

至于楼上提到的，恐怕是最近几年兴起的template metaprogramming，
在loki中看到的几乎所有metaprogramming技术，都并非loki首创，基本来自comp.lang.c++.moderated；且boost中的实现好得多，也更为C++社群接受。

现在不少C++编译器对模板的支持非常好，gcc就不错，而合并了kcc的intel c/c++编译器表现也相当出色。有了Lippman加盟的vc自然不会让我们失望。事实上，基于expression template技术的类库已经遍地开花，bs来华的讲座就提到了这一点，他就展示了MTL库。

我个人以为，bs强调的是各种paradigm保持平衡，不要期望任何一种是万灵丹。如果想用GP代替OO的一切，未免不太现实。andrei向我们展示的，仅仅是C++可以做什么，而并非C++要这么做。看看他对min/max的实现，您会用吗？用他自己的话说，他更像是在做挑战，在做一个登山者，而并非一个为我们普通程序员开路的人。不过话说回来，我还是很欣赏他提的policy和scope_guard（虽然bs在TC++PL里早就写了），呵呵。

我并不认为Loki是想用GP代替OO，恰恰相反，我认为Loki是试图用GP来表达模式。设计模式当然可以包含OO，但并不局限于OO，但是不管一个模式是否包含OO，都不影响用GP来表示它。我现在的看法是：GP和OO是两个不同的东西，他们从来就没有发生过矛盾，将来也不会发生矛盾。

-------------------------------------------------------------------
根据我的理解，Loki库沿用的是Metaprogramming的思路，当你一遍又一遍地运用同一个模式时，必然会写出一系列非常相似的代码，其中肯定是有一些规律性的东西的。Loki认为它可以用模板技术自动生成精确地包含了特定模式的C++代码，如果该模式要求Dynamic Dispath，它当然要生成包含Dynamic Dispath的代码。换句话说，模板类生成的类当然可以是传统的多态类，这里面并不存在矛盾。我认为Loki的思路是很自然的，这里的关键是设计模式能不能用代码库来表达？对库的基本要求是通用而又不失精确性，这里的精确性对于STL来说就是不能丧失效率，对DP来说就是不能丧失灵活性。
-------------------------------------------------------------------
我记得Alexander Stepanov说过GP和Static Type没有任何关系。我曾对这句话非常困惑，一位网友就此谈到：
hello, anrxhzh, I agree with you. It absolutely can't load the file
dynamically the same way as we mention in Think in c++ because GP use static type check. But, it does't matter, because you can overload >> and << operator to realize dynamic file loading and type checking.The key point of GP is that it offer a higher abstraction than that of normal OO design, and give us a clear, easy to extend interface.You mentioned that there is no relationship between GP and static type. It's right because they deal with different things. How did you think if a template class in which a virtual function is defined? 

我没说loki是用gp代替oo啊，loki是想用gp实现oo patterns，而不是像有些人寻找dp在gp的表现形式。

loki并不是沿用metaprogramming的思路，loki的思路是tc++pl里提到的policy，通过功能正交的policy组合出所谓的泛型组件。我觉得他组合出smart pointers很好，但是企图组合出模式就太笨拙，连SINGLETON都组合不出来。至少从现在已有的经验来看，SINGLETON很难写成代码，其他模式就更不用说，再加上模型相互的组合，这就更加困难。

to babysloth,

对不起，我觉得你没有明白我的意思。呵呵。我和你的观点基本上没什么冲突。

你谈到了template metaprogramming, expression template, mtl等, 我也就接话查说两句，谈谈我对其的感受，与感兴趣的朋友交流。不对的地方还望babysloth兄和其他朋友斧正。

C++ template metaprogramming说句实在话是比较免强的。不管是loki也好，boost也好，看看说位的metaprogramming 使用起来有多别扭吧。(这一点与C++编译器对模板的支持得好坏无关。) 为什么会如此呢？原因就是C++不支持编译期计算。在编译期计算上, C++缺乏基本的计算的流程控制语法, 不支持float 常量作为编译期计算的“变量", 不支持数组，无metaprogram 结构的语法，等等。(当然，用C++ templates能把这些东西全都模拟出来，但(有些方面）至少语法将糟糕的一塌糊涂）长话短说，就一句话：templates 支持的是generic programming, 不支持metaprogramming。目前的 C++ template metaprogramming 给我的感觉像用C做OOP。

另外，expression template 要说也是一overuse魔板的典型了(所以说overuse不一定是不好）。要我说，它比那template mateprogramming 可读／写／理解／维护性还糟糕。呵呵。除非万不得已，千万别自己写expression template code, 用别人写得库。

最后，据我所知，mtl没有用expression template (难道有新版？）。mtl提供的语法比较烂。象：
mult(mat, vec1, vec2);
还真不如去用linpack什么的。

您试试boost.mpl，我觉得这样用C++做metaprogramming就很自然了

typelist我最早是在99年出的generative programming一书里看到，里面是用整数作模板参数，不是类型，不过大同小异。andrei也坦承loki里的typelist来自该书和新闻组上的讨论。我上面几个帖子的意思，并不在对metaprogramming有何看法，我只是反对用template来描写OO方式的模式。

另外，对于C++的应用程序和程序库，我个人以为是要求是完全不同的。库的责任是使接口友好，至于实现您自己如何看不惯，认为它如何如何“糟糕的一塌糊涂”，那都无关紧要。而我们自己写的应用程序本身就不同，要讲究可读性和可维护性。C++的模拟能力非常强，就在于它写出的程序可以提供友好的接口，不管是smalltalk式OO，gp，functional programming还是metaprogramming。接口友好，这就足够，库的实现与我们无关。至于库本身的实现，我相信随着mpl和preprocessor之类技术的发展，总会越来越方便的。

ps: ET（expression template）是David Vandevoorde发明的，我最早看到是todd在blitz++里先用，既然是好技术，mtl自然也不会客气。mtl原来是没用ET，语法极恶，后来也忍不住诱惑，开始改变（http://www.lsc.nd.edu/~jsiek/mxtl.html）。

我完全能理解bs对loki and Andrei的评价。我对loki的patterns不感冒，基本原因在我上贴中已经说了，这里再就anrxhzh(百宝箱) 兄的问题具体说一下。

anrxhzh(百宝箱) 兄提出：为什么templates能很好的处理algorithms, 而处理patterns时就这么不招人喜欢呢？（这不是原话，希望没有误解anrxhzh(百宝箱) 兄的意思）

short answer 是algorithms 处理的是运行期物件间的关系，而patterns要处理的是编译期"物件"(types)间的关系, 而编译期"物件"(types)间的关系是不大可能用C++ templates 进行很好地描述的。

long answer 是... (此处略去一千三百二十七个字:）

不过，我想要强调的是modern c++ design是在展示一种思想 (而不是一本loki的manual), 还是那句话 - 真正的"C++编程思想", 不单是policy-based design, express OO patterns in C++ templates, 还有更多的蕴含东西，具体的以后有空再说吧。

babysloth,

我不是仅仅说库“糟糕的一塌糊涂”，我是说所有的程序呀。比如：在编译期处理常量字符窜，不用"糟糕的一塌糊涂的语法"是不可能用目前的C++ templates 做出来的, 没有库能把语法变得简单优美的。

(ps. mtl 的link收到，多谢）

不明白，举个例？

ps 不客气

比如: 给定任意字符串常量, 统计里面某个字母的个数. 举例:

const char* const aStringLiteral = "abaafdfkaajdlaeajflafda";
...
CountLetter<aStringLiteral, 'a'>::value;  // 希望value是个常数, 等于'a'在aStringLiteral中的个数. 如何实现CountLetter<...>?

然后呢？有什么不对的吗？
您是指缺乏template typedef带来的语法？

CountLetter<aStringLiteral, 'a'>::value;

这只是我期望的, 用来说明我要的功能. 这么个"CountLetter"是不可能实现的. 这个功能倒是能实现的, 但语法就没那么干净了, 可以说是惨不忍睹.

中午本来想发言的, csdn抽风, 结果白写了.....wuwu.....没有天理....

singleton这样的模式, 现在还有找到完美的做法, 哪里谈得上抽象...所以一点也怪不得loki.. ;-)

而且也不是说loki实现的模式不好, 但是它没法实现模式组合的模式, 或者模式组合的模式组合的模式..或者......., 写一个东西, 不是有一个模式就用一个模式. 而是大家相互影响的. 所以loki库中最成功的, 不是模式, 而是基于policy的功能模块的实现, 比如smart_ptr(//hand 虫虫). 

偶不是说pattern不能用模版实现, 不是这个意思. 偶是说, pattern这个东西没法拿来做库. 不能用户来主导设计, 而是只能作成一个framework来引导用户进行设计, 大致和mfc那样.

关于template expression, 其实也不是特别的复杂. 说是不提倡自己动手写, 是怕你累着, 小心一点, 自己写到也不是什么大不了的事情....

像一个静态的CountChar之类的东西, 我觉得没什么困难的, 模版的递归调用最擅长处理此类问题, 如果有问题, 那也是编译器能支持模版嵌套的强度的问题.

另外白活两句, 当初j. v.(就是gof里面的一个, 偶不记得名字了)对mcd似乎很是欣赏.......记得还看到过他和andrei合作的两片东西, 好像是C++ report的专栏来着.....

"To Code or Not to Code II", C++ Report, March and June 2000, in co-authorship with Dr. John Vlissides. 
"To Code or Not to Code I", C++ Report, March and June 2000, in co-authorship with Dr. John Vlissides. 

http://www.moderncppdesign.com/publications/main.html

看起来Generic Pattern Implementations (GPI)能够起多大的作用，取决于实现者和使用者对特定模式的认识深度，而GPI本身是当前条件下极具创造性的构想，在我看来简直是极致了。

用 template 展开之类的方法来实现 pattern ，我认为是做不到的，至少在目前。原因也比较简单，对于 pattern 还没法精确的，形式化的描述它。什么时候那 23 个模式可以象 stack、qsort 一样用形式化的语言非常精确的描述出来了，那时候我们就可以期待用很少的几行东东指明：我这里要一个 Decorator，这里要一个 Chain of Responsibility …… 

PS：cber 你什么时候成了 GP 版的版主了？

//hand Elminster :-)
我觉得关键在于有没有持续的需求，希望重复的在程序中实现dp这一相对低效的工作能被机器代劳。只要有这样的需求，完成这样的飞跃是有可能的，至于最终是以什么形式实现倒无关重要。在目前的编译器限制下难以实现，并不等于不能做或者没有必要做，如果这样的思想实验（相对于设计编码运行实验而言）显示dp library具有足够的必要性，为这种想法而修订标准并非不可想象的事情。目前我想对dp的形式化描述是我们首先要做的工作，然后要解决的问题是为了高效优雅的实现这些描述，我们对编译器有什么期待。简单来说，我们不是装修外墙，而是加建楼层。

很有道理。STL的诞生有三个先决条件：一是前人对算法和数据结构的理论研究已经建立了非常坚实的土壤；二是STL的创造者在这片土壤上对算法和数据结构的分类学有着独到的建树；三是当时的C++提供了合适的表达工具。目前在设计模式领域恐怕连第一个条件都还没有满足。

to 伊尔明斯特：

你的这种希望，听起来比较玄。对于设计模式，本来每个人的想法都是不一样的。还以Singleton为例，有人只想要一个最简单的；有人想得多一点，希望能有一些OO的特性在里面；有人要得更多一点，希望能thread-safety。每个人都说Singleton，其实心里想的都不是同一个东西，还谈什么形式化描述？

或者可以换个角度来说，就是我们对复用的期望值太高。自己脑子里面想的东西（或者叫需求）根本都没办法形式化，就希望能有一些东西可以复用，我很直觉地就觉得这不大可能。仍以Singleton为例，简单的Singleton（例如GoF版）招人骂，因为它不好用；复杂的Singleton（例如Loki版）还是招人骂，因为它太复杂。每个人的想要的东西就不一样，怎么可能有一个库来适应所有人的要求呢？

所以（顺便回应纸起重机），首要的问题恐怕还不是形式化描述设计模式，倒是形式化描述需求。不过，设计模式也可以（以某种形式）用来描述需求。再申发下去，就out of my control了，就此打住。

to SHIZUMARU(绯雨闲丸):
有同感。大家何不描述一下各自曾遭遇过的对各种dp的要求以及实现上的挫折（我觉得好像在引导客户作需求^_^）。

To 绯雨闲丸

对呀，设计模式本身到目前为止还只是一个经验总结式的东西，两个不同的人说起同一个模式来想的还不是同一个东西，你如何让没有智能的计算机来处理模式的自动生成？

正因为如此，才要引入模式的形式化的描述，首先你得精确定义一个模式是什么，然后精确定义这个模式的各种衍生变形及扩展，最后才是自动生成。拿哈希表做例子，首先定义什么是哈希表：键和值之间通过哈希函数映射的线性表，然后再定义各种不同的冲突处理方式：链地址、再哈希、线性探测 …… 有了这么一套完整的精确的定义，今天的 SGI STL 才能让你用几个模板参数就自动的生成出一个能工作的 hash_map 来。

至于说到形式化的描述需求 …… 这就是从古到今程序员所做的唯一的事情啊，把用户提出的模糊的需求形式化的描述下来 ——— 结果就是软件。

To papercrane

纸鹤就纸鹤吧，纸起重机 ……

to Elminster:
周围的人都叫我起重机，你是为我正名的唯一一个，来广州敲我一顿好不好:)

我认为，所谓的gp只是在一定范围内的，至于范围的大小这是决定是否可以实现的条件。任何事物的实现都是有条件的，gp也不例外，现在提出的模式只是一种概念如果要实现的话肯定要有很雄厚的技术职称更是在一定程度一定范围里使用而不是overuse or abuse.任何东西都有可能被 over or abuse 我们要做的是如何受
控制的使用。

模式只是一个抽象，同样也有一定的限制的，事物的抽想是有层次的可以被不断的细分，如果坚持要无论何事都要用模式来处理，等于是一个“永动机”的理想错误还是要，在一定范围，一定情况下来使用。

模式肯定是一种新方法,但是他不是我们的全部。

控制的使用,这才是关键！

mark