名家评论：
闲谈 D&E (专家孟岩 王曦于2003-10-10 4:08:11) 2人同意、0人反对
闲谈 D&E
D&E是指C++之父Bjarne Stroustrup的力作The Design and Evolution of C++一书。在这本书中， Stroustrup回顾了从80年代初到90年代中期C++的发展历史，对诸如GC等各种设计权衡进行了反思，并展望了C++未来的发展方向。2002年，D&E一书的中文版和英文影印版都由机械工业出版社在国内推出，这着实让广大的C++迷们兴奋不已。
下面为两位C++爱好者梦魇（myan）和虫虫（babysloth）对此书的一次聊天语录。
虫虫：记得以前托朋友从清华的图书馆里借出D&E，我们一帮C++迷还花了不少银子来复印。谈到中文版，我们对它的出版普遍抱悲观的态度。毕竟是1994年的书，距现在也好几个年头了。没想到国内这次不仅出了英文影印版，北大的裘宗燕教授还翻译了中文版，两本书双双出版了。
梦魇：的确是这样。年代这么“久远”的科技书籍，还能引起这么大的反响，不容易。特别是在计算机这种技术发展一日千里的领域，更是难能可贵。但是，仅仅抱着收藏古董的心情来读这本书，收获未必很大。
虫虫：刚开始时，我是抱着看历史的想法来读D&E，主要想看看C++设计过程的一些想法。后来，随着阅读的深入，却发现这本书所蕴涵的并不只是这些东西，它还不时地引起我们对程序设计的反思。例如，许多人误以为是 Java首先引入了GC（Garbage Collection，裘教授译为“废料收集”），其实不然。实际上，在C++中，就已经经历了多次的比较和权衡，只不过最终决定放弃。看到10.7节（Automatic Garbage Collection）的时候，才知道当年Stroustrup已经非常深入地考虑了这个问题。过了几年 Java热起来，开始批评C++没有GC功能。其实看看D&E就能知道设计者的考虑权衡。
梦魇：每当网络上有人批评C++设计的时候，Stroustrup都让他们去读这本书。潜台词可能是：如果你没读过我这本书，就不要妄自批评C++的是非。我想任何人只要认真读过这本书，就可以理解他的态度。 很多所谓的设计“缺陷”，其实是一种设计抉择，一种设计权衡（trade-off），是为了更重要的目标，而对较次要的目标所作出的牺牲。就拿GC这个问题来讲，从我的OOP实践来看，一种面向对象设计语言没有GC机制的辅助，难度会大大增加，同时也会给系统带来很多隐患。 所有面向对象语言都是基于指针语义，内存的分配与回收是无论如何也绕不开的问题。没有GC，你在设计里就不得不做一大堆额外的复杂工作。所以，现在流行的一些OOP语言新贵都不约而同地加入了GC机制。既然如此，为什么C++不内置一个GC呢？我曾经就此问题请教过本书的译者裘教授，他很明白地解释道， GC的有效性和高效性存在不可调和的矛盾，这种矛盾涉及到冯·诺依曼计算机体系的本质问题，无法消解。所以我们不可能找到一个令各方都满意的GC机制，那么内置GC，就违背了C++更重要的 原则。反过来说，没有GC的C++可以以多种手段获得GC的效果。 Stroustrup说过，在他的哲学里，尊重人群而不尊重人群中的个体实际上就是谁也不尊重。所以，这个选择权留给用户自己。
虫虫：Stroustrup这个思想很值得回味。 C++的 定位 是通用性的语言，与 Java和C#的 专有语言有巨大的定位落差。 C++不会为了某一个群体而抛弃另一个群体，我想读读D&E，在这些方面都大有收获吧。
梦魇：对，就我个人而言， 阅读这本书主要的收获是两个，一是了解C++的设计选择，从而帮助我更牢固地掌握C++知识。二是通过对一些设计原理的阐述，让我能够更好的思考几个问题：什么情况下应当使用C++，什么情况应该优先使用其他语言？如何更合理的使用C++？
虫虫：巩固知识的作用是显然的，我倒是对如何合理使用C++的思考很好奇。“合理”毕竟不好定位啊……
梦魇：首先来说，这本书对于各个特性都进行了描述，其实就体现出，在作者脑子里，这个特性怎么用算是“正确”的用法。比如说 C++的异常为什么没有finally，那就是因为作者认为所有的清理性工作应当在析构函数中进行。读到这里，你就会对C++提出的资源解决方案有一个原则性的认识，用的时候就会知道该怎么用。还有，比如C++强调静态强类型，可又设计了RTTI，那么象typeid这样的东西，用在什么地方算是合适的，什么地方属于滥用？读这本书会有一个基本的看法。
虫虫：说道这里我想到一个问题，象 RTTI这种纯OOP的概念，似乎在C++里并没有得到很大的重视，现在的 Java、C#都极力地增强这方面的能力。
梦魇：为什么会这样呢？这正是我们阅读D&E所能够获得的东西。从这个角度来讲，D&E是独一无二的。我个人觉得，对于C++在OO方面的运用，我们还需要很长时间的探索。现在在泛型方面取得很大的进展，倒是 在OO方面，C++陷入一个困境，当然这纯属我个人观点，可能很多人都不同意。去年在与Stroustrup往来的email中，我们问他如果能给C++程序员提几个建议，他会说什么，还记得他怎么回答的？
虫虫： 第一个建议在意料之中，如果 能用标准库，尽量用标准库。可是 第二个建议很耐人寻味，尽量 把基类设计成抽象类。我们当时就在讨论，这样一个简单而不起眼的原则，为什么会被他这么郑重其事地举出来。
梦魇：我个人认为这就是他对于 C++在OO风格上的反思，而这种反思，在这本书里已经有了很多的体现。
虫虫：你认为C++需要这种反思吗？
梦魇：我觉得很必要。就拿刚才说道的那个原则来讲，Stroustrup实际上已经默认了， 如今OO的主要目标是接口的复用，而不是早些年所宣传的基类代码复用。
虫虫：代码复用更多的由模板技术来体现，现在模板库成堆。
梦魇：似乎有这个趋势。总的来说，代码复用的重要性在下降，起码在OO中的是在下降。制造 可插拔的组件，是OO发展到今天所探索出来的方向。不过， 本质上C++是一种用来解决问题的语言，不是用来布道的语言，C++不是用来宣扬OO宗教的。OO只是一个工具，C++的手段之一，它是服从与解决问题的大局的，是佣人，不是主子。所以说，我们有些人用C++，一上来就对象分析，构造庞大的继承层次，这种方式对Java可以，对Smalltalk可以，究竟适不适合C++，很值得考虑。
虫虫：我也有过这种思考。OO最早是保罗阿托实验室跟Smalltalk一起出来的思想， 人们首先从Smalltalk那里了解到什么是OO，然后才开始大规模地用C++实现OO。所以做的第一件事就是想办法用C++模拟Smalltalk。结果过了这么多年，才感到这种方式不太对，Stroustrup就曾经感叹，没有一个库来展现好的OO设计。不能否认，MFC在实际应用中非常广泛，非常成功。然而连Charles Petzold也不讳言， MFC的设计是失败的，发展到7.0，已经臃肿不堪。
梦魇：原因是什么？就是因为 人们没有针对C++本身的特点，探讨具有C++特色的OO主义道路，而是照办照抄Smalltalk经验。现在回过头去看1994年出版的这本D&E，感到Stroustrup对这个问题一开始就有比较清醒的认识，但很可惜没有得到足够的重视。
虫虫：模板机制出现在C++中没几年，人们就得到了STL这样一个如此精美的GP库。然而OO出现如此长的时间，却没有一个库可以在理论上称之为完美，恐怕的确值得大家反思。Taligent公司的往事，都是值得人们借鉴的。比如说在第9章，他指出 在通用应用程序设计方面，C++并不是十分理想。在更大规模的程序里，除非C++实现了可选的GC，否则就会遭受挫折。现在看来都是真知灼见。
虫虫：从这里以至后来的一些事情，我得到一个教训是， 不要迷信权威的同时，也绝对不可过于自信。大师之所以为大师，专家之所以为专家，是有他们的本钱的。记得当时看Boost中的smart pointer库实现，觉得纳闷：smart pointer可以有很多种实现，可能比Boost的方法更好啊。后来看到文档里的一篇说明，详细分析了各种实现的优劣，并给出了在各种情况下不同实现的性能数据及图象。我一下子觉得自己太幼稚了，我们现在的那一点经验，还远远不到可以评论C++这里有缺陷、应该那样做更好的程度。尊重别人，才能尊重自己。
梦魇：呵呵，是这样的。这个阶段我想很多人都经历过。我们中国人非常看重独立思考能力，这当然是好事，但是往往 片面地抓住一点就自以为了不起。其实更多地了解别人的意见，是相当有裨益的。
虫虫：就像一壶有些年头的酒，作为一本有些年头的书，D&E很值得回味。比如15.4节谈到Constraints on Template Arguments，即所谓type checking，也就是对模板参数的类型检查问题，那时候已经引起了Stroustrup的重视。他说 本想为C++加入type checking机制，但是觉得不太成熟，还是交由C++社群来发展。因为面向对象可以通过编译器进行类型检查，而模板参数则不可能，会带来调试上的困难。那时候STL还没出现（在写这本书的时候应该还没出，因为关于STL的消息是作为8.5节脚注，而非正文）。STL之父Alexander Stepanov一直以来就考虑了这个问题，后来归结为concept checking问题；数年之后，最终在SGI STL中得以实现，并提交给Boost，成为Boost Concept Checking Library，趋于成熟。后来这种技术也应用在BGL（Boost Graph Library）上，效果相当不错。联系现在和书上BS这段话，不由不佩服他的远见卓识。
梦魇：对。其实从D&E这本书中，我们还可以……
闲谈 D&E (专家孟岩 王曦于2003-10-10 4:08:11) 2人同意、0人反对
闲谈 D&E
D&E是指C++之父Bjarne Stroustrup的力作The Design and Evolution of C++一书。在这本书中， Stroustrup回顾了从80年代初到90年代中期C++的发展历史，对诸如GC等各种设计权衡进行了反思，并展望了C++未来的发展方向。2002年，D&E一书的中文版和英文影印版都由机械工业出版社在国内推出，这着实让广大的C++迷们兴奋不已。
下面为两位C++爱好者梦魇（myan）和虫虫（babysloth）对此书的一次聊天语录。
虫虫：记得以前托朋友从清华的图书馆里借出D&E，我们一帮C++迷还花了不少银子来复印。谈到中文版，我们对它的出版普遍抱悲观的态度。毕竟是1994年的书，距现在也好几个年头了。没想到国内这次不仅出了英文影印版，北大的裘宗燕教授还翻译了中文版，两本书双双出版了。
梦魇：的确是这样。年代这么“久远”的科技书籍，还能引起这么大的反响，不容易。特别是在计算机这种技术发展一日千里的领域，更是难能可贵。但是，仅仅抱着收藏古董的心情来读这本书，收获未必很大。
虫虫：刚开始时，我是抱着看历史的想法来读D&E，主要想看看C++设计过程的一些想法。后来，随着阅读的深入，却发现这本书所蕴涵的并不只是这些东西，它还不时地引起我们对程序设计的反思。例如，许多人误以为是 Java首先引入了GC（Garbage Collection，裘教授译为“废料收集”），其实不然。实际上，在C++中，就已经经历了多次的比较和权衡，只不过最终决定放弃。看到10.7节（Automatic Garbage Collection）的时候，才知道当年Stroustrup已经非常深入地考虑了这个问题。过了几年 Java热起来，开始批评C++没有GC功能。其实看看D&E就能知道设计者的考虑权衡。
梦魇：每当网络上有人批评C++设计的时候，Stroustrup都让他们去读这本书。潜台词可能是：如果你没读过我这本书，就不要妄自批评C++的是非。我想任何人只要认真读过这本书，就可以理解他的态度。 很多所谓的设计“缺陷”，其实是一种设计抉择，一种设计权衡（trade-off），是为了更重要的目标，而对较次要的目标所作出的牺牲。就拿GC这个问题来讲，从我的OOP实践来看，一种面向对象设计语言没有GC机制的辅助，难度会大大增加，同时也会给系统带来很多隐患。 所有面向对象语言都是基于指针语义，内存的分配与回收是无论如何也绕不开的问题。没有GC，你在设计里就不得不做一大堆额外的复杂工作。所以，现在流行的一些OOP语言新贵都不约而同地加入了GC机制。既然如此，为什么C++不内置一个GC呢？我曾经就此问题请教过本书的译者裘教授，他很明白地解释道， GC的有效性和高效性存在不可调和的矛盾，这种矛盾涉及到冯·诺依曼计算机体系的本质问题，无法消解。所以我们不可能找到一个令各方都满意的GC机制，那么内置GC，就违背了C++更重要的 原则。反过来说，没有GC的C++可以以多种手段获得GC的效果。 Stroustrup说过，在他的哲学里，尊重人群而不尊重人群中的个体实际上就是谁也不尊重。所以，这个选择权留给用户自己。
虫虫：Stroustrup这个思想很值得回味。 C++的 定位 是通用性的语言，与 Java和C#的 专有语言有巨大的定位落差。 C++不会为了某一个群体而抛弃另一个群体，我想读读D&E，在这些方面都大有收获吧。
梦魇：对，就我个人而言， 阅读这本书主要的收获是两个，一是了解C++的设计选择，从而帮助我更牢固地掌握C++知识。二是通过对一些设计原理的阐述，让我能够更好的思考几个问题：什么情况下应当使用C++，什么情况应该优先使用其他语言？如何更合理的使用C++？
虫虫：巩固知识的作用是显然的，我倒是对如何合理使用C++的思考很好奇。“合理”毕竟不好定位啊……
梦魇：首先来说，这本书对于各个特性都进行了描述，其实就体现出，在作者脑子里，这个特性怎么用算是“正确”的用法。比如说 C++的异常为什么没有finally，那就是因为作者认为所有的清理性工作应当在析构函数中进行。读到这里，你就会对C++提出的资源解决方案有一个原则性的认识，用的时候就会知道该怎么用。还有，比如C++强调静态强类型，可又设计了RTTI，那么象typeid这样的东西，用在什么地方算是合适的，什么地方属于滥用？读这本书会有一个基本的看法。
虫虫：说道这里我想到一个问题，象 RTTI这种纯OOP的概念，似乎在C++里并没有得到很大的重视，现在的 Java、C#都极力地增强这方面的能力。
梦魇：为什么会这样呢？这正是我们阅读D&E所能够获得的东西。从这个角度来讲，D&E是独一无二的。我个人觉得，对于C++在OO方面的运用，我们还需要很长时间的探索。现在在泛型方面取得很大的进展，倒是 在OO方面，C++陷入一个困境，当然这纯属我个人观点，可能很多人都不同意。去年在与Stroustrup往来的email中，我们问他如果能给C++程序员提几个建议，他会说什么，还记得他怎么回答的？
虫虫： 第一个建议在意料之中，如果 能用标准库，尽量用标准库。可是 第二个建议很耐人寻味，尽量 把基类设计成抽象类。我们当时就在讨论，这样一个简单而不起眼的原则，为什么会被他这么郑重其事地举出来。
梦魇：我个人认为这就是他对于 C++在OO风格上的反思，而这种反思，在这本书里已经有了很多的体现。
虫虫：你认为C++需要这种反思吗？
梦魇：我觉得很必要。就拿刚才说道的那个原则来讲，Stroustrup实际上已经默认了， 如今OO的主要目标是接口的复用，而不是早些年所宣传的基类代码复用。
虫虫：代码复用更多的由模板技术来体现，现在模板库成堆。
梦魇：似乎有这个趋势。总的来说，代码复用的重要性在下降，起码在OO中的是在下降。制造 可插拔的组件，是OO发展到今天所探索出来的方向。不过， 本质上C++是一种用来解决问题的语言，不是用来布道的语言，C++不是用来宣扬OO宗教的。OO只是一个工具，C++的手段之一，它是服从与解决问题的大局的，是佣人，不是主子。所以说，我们有些人用C++，一上来就对象分析，构造庞大的继承层次，这种方式对Java可以，对Smalltalk可以，究竟适不适合C++，很值得考虑。
虫虫：我也有过这种思考。OO最早是保罗阿托实验室跟Smalltalk一起出来的思想， 人们首先从Smalltalk那里了解到什么是OO，然后才开始大规模地用C++实现OO。所以做的第一件事就是想办法用C++模拟Smalltalk。结果过了这么多年，才感到这种方式不太对，Stroustrup就曾经感叹，没有一个库来展现好的OO设计。不能否认，MFC在实际应用中非常广泛，非常成功。然而连Charles Petzold也不讳言， MFC的设计是失败的，发展到7.0，已经臃肿不堪。
梦魇：原因是什么？就是因为 人们没有针对C++本身的特点，探讨具有C++特色的OO主义道路，而是照办照抄Smalltalk经验。现在回过头去看1994年出版的这本D&E，感到Stroustrup对这个问题一开始就有比较清醒的认识，但很可惜没有得到足够的重视。
虫虫：模板机制出现在C++中没几年，人们就得到了STL这样一个如此精美的GP库。然而OO出现如此长的时间，却没有一个库可以在理论上称之为完美，恐怕的确值得大家反思。Taligent公司的往事，都是值得人们借鉴的。比如说在第9章，他指出 在通用应用程序设计方面，C++并不是十分理想。在更大规模的程序里，除非C++实现了可选的GC，否则就会遭受挫折。现在看来都是真知灼见。
虫虫：从这里以至后来的一些事情，我得到一个教训是， 不要迷信权威的同时，也绝对不可过于自信。大师之所以为大师，专家之所以为专家，是有他们的本钱的。记得当时看Boost中的smart pointer库实现，觉得纳闷：smart pointer可以有很多种实现，可能比Boost的方法更好啊。后来看到文档里的一篇说明，详细分析了各种实现的优劣，并给出了在各种情况下不同实现的性能数据及图象。我一下子觉得自己太幼稚了，我们现在的那一点经验，还远远不到可以评论C++这里有缺陷、应该那样做更好的程度。尊重别人，才能尊重自己。
梦魇：呵呵，是这样的。这个阶段我想很多人都经历过。我们中国人非常看重独立思考能力，这当然是好事，但是往往 片面地抓住一点就自以为了不起。其实更多地了解别人的意见，是相当有裨益的。
虫虫：就像一壶有些年头的酒，作为一本有些年头的书，D&E很值得回味。比如15.4节谈到Constraints on Template Arguments，即所谓type checking，也就是对模板参数的类型检查问题，那时候已经引起了Stroustrup的重视。他说 本想为C++加入type checking机制，但是觉得不太成熟，还是交由C++社群来发展。因为面向对象可以通过编译器进行类型检查，而模板参数则不可能，会带来调试上的困难。那时候STL还没出现（在写这本书的时候应该还没出，因为关于STL的消息是作为8.5节脚注，而非正文）。STL之父Alexander Stepanov一直以来就考虑了这个问题，后来归结为concept checking问题；数年之后，最终在SGI STL中得以实现，并提交给Boost，成为Boost Concept Checking Library，趋于成熟。后来这种技术也应用在BGL（Boost Graph Library）上，效果相当不错。联系现在和书上BS这段话，不由不佩服他的远见卓识。
梦魇：对。其实从D&E这本书中，我们还可以……
635
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
