《C++语言的设计和演化(英文版)》的原文摘录

  • 本书的宗旨就是想把这些目标见诸于文字,追溯其演化过程,描述C++是如何从许多人为建立一个语言而努力中浮现出来,并按照这些目标为它的用户服务的。 (查看原文)
    杰良 2012-12-16 02:10:37
    —— 引自章节:第0章
  • 语言绝不能仅仅是一些“精巧”特征的汇集 每种语言的设计都是为了解决一个特定问题集合里的问题,在某个特定时期,依据某个特定人群对问题的理解。由此产生了初始的设计。而后它逐渐成长,去满足新的要求,反映对问题以及对解决它们的工具和技术的新理解。 (查看原文)
    杰良 2012-12-16 02:10:37
    —— 引自章节:第0章
  • 看起来对每个可能的语言及其每种使用都存在“很好的证据”,我们还需要数据。如果没有数据和适当的评估试验,我们就会像那些希腊哲学家,他们确信宇宙中的所有东西都是由某几种物质组成的,他们天才地辩论了几个世纪,然而还是无法确定究竟是哪四种(或者是五种)基本物质。 (查看原文)
    红色有角F叔 2013-09-28 09:41:20
    —— 引自第268页
  • 为了做出可靠的系统,你需要尽快地把非同步事件映射到某种形式的进城模型中。 低级中断系统应该尽可能与普通程序分离。 (查看原文)
    红色有角F叔 2013-09-28 10:00:34
    —— 引自章节:第十六章 异常处理
  • 标准化绝对不是一件容易的事情。在这个委员会里有各种各样的人,有的人来到这里就是为了维持现状;有的人带着一个有关现状的想法,希望能够把时间拨回到几年之前;有的人希望能与过去做彻底的决裂,设计出一个全新的语言;有的人只关心某一个问题;有的人只关心某一类系统;有的人在投票时完全看他们雇主的脸色行事;有的人只代表他们自己;有的人带着有关程序设计和程序设计语言的理论观点;也有的人希望的事今天就有一个标准,即使这意味着遗留下许多没有结论的问题;有的人则除了一个完美的定义之外什么也不能接受;有的人还认为 C++ 完全是一个新语言,几乎没有什么用户;有的人则代表着再过去 10 年里写出了成百万行代码的用户;如此等等。 在标准化的规则下,我们都必须或多或少表示同意,必须达成“一致”(通常定义为一个很大的多数)。存在一些合理的规则——即使不太合理,它们也是委员会必须遵守的国家或者国际的规则。所有的利益都是合法的,让一个多数压服一个很大的少数的利益,最终将会产生一个标准,它只对某个过分狭隘的用户社团有用。这样,委员会的每个成员都要学会尊重那些看起来是异己的观点,学会妥协。这些倒很符合 C++ 的精神。 (查看原文)
    红色有角F叔 2013-10-01 10:55:49
    —— 引自章节:1985-1993 年表
  • 我过去和现在的印象都说明,许多程序设计语言和工具都是在提供了解答之后再去寻找问题,而我则确定自己的工作绝不能混同于这一类东西。 良好设计的关键是对问题的深入认识,而不是提供了多少最高级的特征。 写它(《C++程序设计语言》 )的时候我带着强烈的决心,不准备去鼓吹任何特殊的程序设计技术。基于同样的想法,我也害怕由于忽视和家长式作风的误导而给语言构筑一些限制。我不希望这本书变成一篇有关自己个人爱好的宣言。 (查看原文)
    红色有角F叔 2013-10-01 11:06:59
    —— 引自章节:第三章 C++ 的诞生
  • 许多人认为子类的信息比它的超类多是有悖常理的。 (查看原文)
    2013-11-23 20:31:43
    —— 引自第42页
  • 语言设计本质上是很有趣的事情,有关新特征的争论使人兴奋,它们为新论文和新的发布提供了口实。 (查看原文)
    2013-12-31 18:59:39
    —— 引自第131页
  • 人们经常对 AT&T 容许其他人实现 C++ 的行为表示诧异,这实际上说明了他们很不了解法律及 AT&T 的目标。一旦出版了 C++ 的参考手册,就再没办法去组织任何人写出一个实现了。进一步说,AT&T 不止是允许其他人加入 C++ 的实现、工具和教育等这样蓬勃发展的大市场,它还欢迎和鼓励他们这样做。大部分人都忽略了这样一个事实,那就是 AT&T 作为程序设计产品的消费者远远大于它作为一个生产者。因此,AT&T 从 C++ 领域的竞争者那里获益匪浅。 (查看原文)
    红色有角F叔 4回复 2014-04-19 23:01:18
    —— 引自章节:7.4.3 期望与看法
  • 我的希望是慢慢地——经常是令人痛苦的慢——推动人们去试验一些新技术,去接受那些适合他们需要或者口味的东西。确实存在着更有效的技术去达到“宗教信仰转变”或者“革命”,但是我极端讨厌这类技术,从根本上怀疑它们在长时间和大范围上的作用。经常看到的情况是,如果一个人可以很容易地转变到“信仰X”,那么进一步地转变到“信仰Y”也是很可能的。这样的收获是短暂的。我喜欢怀疑论者而不是“真诚的信徒”。我把一点点实在的证据看得比许多理论更有价值,把实际经验的结果看得比许多逻辑论述更为重要。 然而,这些观点也很容易导致宿命而接受现状。此外,一个人如果不打破几个鸡蛋是做不出鸡蛋饼的,而且大部分人实际上确实不希望变化——至少“不是现在”,不是以某种可能搅乱了它们日常的生活的方式。这就是需要尊重事实且需要一点理想主义出现的地方。在程序设计领域内,一般地说,世界上事情并不总是处在很好的状态,要改进它们,有许多事情是可以做的。我设计 C++ 只是为了解决一个问题,而不是想证明一种观点,而它的成长又能够服务于它的使用者。这里的基本观点是,完全可能通过逐步改变去达成一种进步。最理想的情景是保持最大的变化速率,而这种变化又确实增加了它所涉及的那些人的福祉。最主要的困难在于确定是什么构成了真正的进步,开发出一些技术以实现平滑的转变,还要避免由于过度狂热而导致的暴行。 (查看原文)
    红色有角F叔 2015-04-06 10:56:47
    —— 引自章节:一般性的背景
  • C++的类的概念和类型系统的一个最重要的考虑就是要支持C++库的设计。它的强弱直接决定了C++库的构型。我对库的建设者和库的使用者的建议非常简单:不要去与类型系统做斗争。与语言的最基础的机制作斗争,即使赢得胜利,那么其代价也必定是昂贵的。优雅,易于使用和效率只能在一个语言的基本框架内得到。如果这个框架对你想做的事情不配合,那么可能说明你需要考虑其它语言了。 C++的基本结构鼓励一种强类型的风格的程序设计。C++里一个类就是一个类型。继承的规则,抽象类的机制和模版机制的组合,都是想鼓励用户严格依据它们为使用者提供的接口去操作各种对象。更直接的说就是,不要用强制类型转换去打破类型系统。强制类型转换对于许多低级操作是必须的,偶尔也用来把高层的东西映射到低级的接口上。但是,一个要求用户广泛进行强制类型转换的库,实际上给用户强加了一种过度而又不必要的负担。C语言的printf函数族,void*指针,联合体以及其它低级机制都应该避免出现在库的接口上。因为它们蕴含着类型系统的漏洞。 C++许多年来,C++的发展就向着一个目标,那就是让语言提供充分的支持,以解决用户在试图使用两个独立设计的库时可能出现的各种基本的问题。库的提供者(建造者),也应该考虑自己的库在用户那里同时使用多个库的问题。 1.namespace就是针对不同库里使用同样名字而提供的机制。 2.异常处理为建立一种处理错误的公共模型提供基础。(goole cpp style中禁用C++异常). 3.模版是定义独立于具体类型的容器类和算法提供的一种机制。其中的具体类型可以由用户或者其它库提供 4.构造函数和析构函数为对象的初始化和最后的清理提供了一种公共模型。 5.抽象类提供了一种机制,借助它可以独立的定义接口。与实际被实现的接口类无关。 (查看原文)
    hao 2015-07-07 15:37:49
    —— 引自第150页
  • 多处理器系统正在变得越来越常见,但同时也出现了令人吃惊的高速单处理器,这就蕴含了至少两种形式的对并行的需要。在单处理器上的多线程和多处理器上的多进程。此外还有很多的专有系统结构。正是由于这种多样性,我建议在C++里应该通过库的方式表述并行,而不是通过某种通用的语言特征。 (查看原文)
    hao 2015-07-07 16:50:13
    —— 引自第155页
  • C++规模很大的一个基本原因就是它要支持不止一种编程范式去写程序。(面向对象,面向过程,函数式等)。它始终存在这多种设计选择,但是在大多数语言里面,语言的设计者都为你作了选择。对C++我们这么做,而是把选择的权利交给了你。 每种不只有简单应用的语言都需要成长,以满足用户社区需要。这就意味着复杂性不断的增长。C++正是这趋势的一部分。它趋向于一个更大复杂性的语言,以便能处理人们想解决更加复杂得多的任务。 如果复杂性不出现在语言本身,那么它必定出现在库或者工具方面。 (查看原文)
    hao 2015-07-07 17:41:34
    —— 引自第164页
  • 抽象类概念的重要性在于它能使人对于用户和实现者做更清晰的划分,能做得比没有它的时候更好。一个抽象类就是一个纯粹的接口,对应的实现是通过由它派生的类提供的。 (查看原文)
    hao 2015-07-09 09:21:51
    —— 引自第232页
  • 抽象类中virtual函数 = 0的语法形式是从许多明显的选择(引入pure关键字或者abstract关键字)中挑出来的,因为那时我觉得不可能再让人接受一个新的关键字。如果引入的pure关键字,那么就不会有抽象类了。与其挑起一场油管pure的战争,我还是采用了C/C++命名的习惯,用0表示“不在那里”。 (查看原文)
    hao 2015-07-09 09:21:51
    —— 引自第232页
  • 类的static数据成员是这样的一种成员,它只存在一个唯一的拷贝,而不像其他成员那样在每个对象中各有一个拷贝。因此不需要引用特定的对象就可以访问static成员。static成员可以用于减少全局名字的数量,并且能把某个static成员逻辑上属于哪个类的问题弄明确,还能实现对这些名字的访问控制。 这种特性对于库的提供商是非常重要的,因为它能够防止对全局名字空间的污染,并可以简化代码库的书写,使同时使用多个库变得更加安全。 在某些情况下,类被简单地当作一种作用域使用,作为它的static成员,以便使这些名字不会污染全局的名字空间。这也是名字空间概念的一个起源。 (查看原文)
    hao 2015-07-09 09:21:51
    —— 引自第232页
  • 强制是C++里面最容易引起错误的功能之一,它们在语法上也是最难看的东西。然而: 任何支持系统程序设计的语言都不可能完全清楚强制,即使是为了有效地支持数值计算,往往也需要某种形式的类型转换。这样,目标应该是尽可能减少强制的使用。 dynamic_cast可能是C++强制中最重要的一部分。 (查看原文)
    hao 2015-07-09 10:23:59
    —— 引自第279页
  • 引进RTTI识别,实际上就是把对象分成两种: 1.一种包含了与之关联的类型信息,因此它们的类型几乎总能被确定,与上下文没联系。 2.另一种不可能。 (查看原文)
    hao 2015-07-09 10:23:59
    —— 引自第279页
  • 只有必须用的时候,才应该明确的使用运行时类型信息。静态编译时检查更安全,带来的开销更少。C++的方式是鼓励尽可能地依靠(更安全更可靠的)静态类型系统,要求用户付出的最小代价也更小一些。 (查看原文)
    hao 2015-07-09 10:23:59
    —— 引自第279页
  • 对于指向类的指针而言,dynamic_cast和static_cast的作用都是在类层次上穿行。reinterpret_cast用来取代T(expr)----原C语言风格的强制,需要谨慎使用 reinterpret_cast。 对于所有的情况,最好是所有的强制------无论是老的新的----都能删除掉。(因为打破了类型系统) (查看原文)
    hao 2015-07-09 10:23:59
    —— 引自第279页