转自: http://www.math.pku.edu.cn/teachers/qiuzy/books/cppl/words.htm
作者 : 裘宗燕
这里讨论一些词汇的译法。在选择术语之前我都仔细想过，尽可能采用常见译法，只有在确实存在有说服力的理由时，我才决定不采用某个流行译法。也有些术语是新问题。下面是一些情况，写在这里请各位评价（起因是在china-pub书评中与读者的讨论，这里经过重新整理，增加了许多材料，以后还会不断增加新内容）：
关于“侵入式”（intrusive）和“非侵入式”设计
将intrusive翻译为“侵入式”是我的个人选择。但“侵入式”和“非侵入式”设计却是软件设计中的一般性问题。这里就此给一个简单解释。
在设计一个类时，按理说，需要考虑的应该只是该类所企图表示的那个“概念”本身：为表示有关概念应记录哪些信息，该类的对象与外界交换信息的界面等等。但定义这个类并不是为了放着观赏，而是为了使用。在考虑类对象的使用时，使用环境和用法的一些要素就可能“侵入”这个类的设计之中。实际上，许多情况下我们常常可以在“侵入式”设计和“非侵入式”设计之间做一个选择，不同选择各有优缺点。在考虑非类的程序部分时，这种问题也同样存在。
例如，我们可能需要对类A的对象做引用计数，这里有两种基本可能性：将计数功能纳入类A的设计内（侵入式引用计数设计，此时类A的对象中包含了与引用计数有关的要素，这显然是与类A所要表示的概念无关的东西），或者将计数功能放在类A之外（非侵入式引用计数）。 本书中讨论容器时提出了“侵入式容器”设计和“非侵入式容器”设计的概念：当我们希望将某个类A的对象放入一种容器时，是否需要将该容器的实现要素“侵入”这个类的设计实现之中（这显然是与类A本身的性质并无必然关系的要素）。不同考虑导致不同的容器设计。
其实在做程序时常常遇到这类问题，只不过国内计算机技术界还没有为此提供一对术语（当然，也可能某些圈子里早有“美妙”的术语，只是我孤陋寡闻）。在翻译《C++程序设计语言》中遇到intrusive一词时，我也考虑了许久，最后才选用了“侵入式”一词，其理由是：该词能很好地反映上述的不同设计考虑，它们也很像是技术术语。后来在另一些书籍文章里又看到intrusive一词，觉得“侵入式”和“非侵入式”这对词汇放在那里同样适用。看来英文的这种说法已经在一定范围中被接受。也就是说，将来在许多技术书籍和文章中都可能遇到这种说法。
我个人希望“侵入式”和“非侵入式”这一对中文术语能被广泛采纳（因为至今我还没有看到、想到更好的词汇）。当然，这只是个人的建议。
1) 许多人将pablic/private说成是“公有/私有”，这两个词的意义与这里所需要的意义根本不符。public/private描述的是使用权：谁有权去访问/使用这些成分：是公众普遍可用，还是内部使用。因此我选择“公用/私用”这一对词。成员的所有权原本就非常清楚，完全不需要额外的描述。
在与网友“虫虫”的讨论中，他提出了一个很好的例证：假定类 B 将其成员 m 定义为 private，类 D 由类 B 派生。在类 D 的对象 d 中有没有成员 m？回答当然是“有”！但是 d 能使用其成员 m 吗？“不能”！因为其基类 B 已经将成员 m 保留为“自己用的了”，这也就是“私用”！由于基类将成员保留为私用，派生类的对象即使“有”此成员但却不能用。这又是“有没有”和“可不可以使用”确实不一样的一个明显实例。
2) friend。不少人用“友员”，我觉得很荒谬。如果讲中文，“友”绝不会是“员”。我们可以有“成员”、“组员”、“队员”等。“友”是另一种关系，绝无从属的意思。因此，friend class我宁可直接用“友类”。但friend function“友函数”读起来别扭，况且还需要有一个词表述一般性的friend和friend关系。因此我选择“友元”，因为“元”并无从属的意思，也常常作为一种构词时的补充。
3) constructor。常见的是“构造函数”。多年来我一直觉得这个词别扭，主要原因有两个：首先是这个词有岐义，“构造”也常（非术语地）作为动词表示去做出什么东西，例如“在我们构造函数时，...”；其次是“构造”作为非术语的使用太多。“建构函数”也是我学来的，看到这个词后觉得很好，原因也是多方面的：它看起来更像个专业名词（这只是感觉）；它很好地描述了constructor的意义和作用；它与“析构函数”有着完美的对称。建议采用“建构函数”还有一个重要理由：在目前自然科学和社会科学的许多领域，construct及其衍生词汇，在作为学术用语时已经被广泛地翻译为“建构”，如“建构主义”等等。当然，“构造函数”一词也还是可以接受的。因此，我在《C++程序设计语言》一书的翻译中就改用了它。但是，从长远观点看，我仍然赞成采用“建构函数”。
而另一方面，“析构函数”似乎不如台湾人用的“解构函数”，但它还不错，可以接受。另一个理由与上面类似，“解构”一词也广泛出现在其他许多领域的学术文章和著作中。长远说，采用“解构函数”是更好的选择。
当然，简单说“构造函数”也是可以接受的术语。因此，在《C++程序设计语言》一书的翻译中我也统一采用了它。但从更大的语言范围看，将 construction 及其相关词汇翻译为“建构”，将 destruction 及其相关词汇翻译为“解构”，已经在其他许多学科领域中广泛采用，包括许多自然科学和社会科学领域。计算机科学技术不应该因为自己“完全由于偶然而产生的差错”就永远游离于更大的学术环境之外。从长远看，我们最好是接受“建构函数”和“解构函数”的术语。
4) inline。不少人用“内联”，我不喜欢这个造出来的新词。发明“内联”者想的是对程序实体的处理方式（加工方式，指将函数代码嵌入调用位置），而inline一词不仅关心这种处理方式，也强调运行方式和情况（指无需经过函数调用步骤而直接运行）。根据这些，我立刻想到的词汇就是“在线”，在各种技术领域常用的与此有关词汇如“在线控制”，“在线处理”，“在线工作”，“在线运行”，“在线设备”等。这些词的意思包括将设备装入加工线，在加工线上处理，在运行中直接做等等。inline function用的正是这个意思。因此我选择了“在线”。
许多年前看到C++的inline机制，当时的认识就是：这是宏与函数概念的结合，可以说它是“类型安全的宏”，或说是“在调用处展开的函数”。我脑子里的两个术语就是inline expanding和inline execution，没考虑应该用哪个中文词。
inline expanding指代码加工阶段将inline函数代码嵌入调用位置代码之中，当然这时还可以做某些优化，可以做一些部分求值（partial evaluation）工作。inline execution则指代码执行时无需创建活动记录（亦称frame），也无需执行函数的入口和出口序列，直接进入函数所生成的代码去执行。在意义上我们一定有共识，否则就不好谈了。
对inline function，目前最常见的译法是“内联”。这是个很怪的词，我觉得不符合中文习惯。“联”指独立实体之间建立关系，常见的词如“联络”，“联系”，“联合国”，“互联网”。过去知道有“外联部”，讲外联也是很合理的。而“内联”就荒唐了，从来只有“连为一体”而不能“联为一体”。“联”就是承认双方（或多方）的独立性。而inline 函数的代码则要与调用处的代码连为一体。因此，估计“内联”是“内连”之误，属于以讹传讹。从这个角度看，“内联”远不如“内连”或者“内嵌”。 但是，“内连”和“内嵌”都难以表示代码执行时的动态情况。“内嵌”还有一个致命弱点，它很容易与（加工前的）静态函数嵌套相混淆。
因为inline函数牵涉到与程序有关的三个时间：源代码，加工后的目标代码，执行。贴切的词确实不容易选。 正是在这种情况下，我选择了可称为“直译”的词。况且，“在线”也能表现代码嵌入（嵌入调用代码行之中，代码行是线性的序列），函数所生成代码的直接执行（在线执行，执行动作也是线性的序列）。当然，“在线”也是online的翻译。从直接的意思看，online是“在线上”，表达某种外物的在线。inline的直接意思是“在线内”，想说的是融为一体，我觉得这也可以称为一种在线。
5）garbage collection。Garbage Collection在中文专业文献中主要有三种译法。80年代起就被称为"废料收集"； 有些讨论数据结构等的计算机书藉中称为"无用单元收集"；近年一些计算机工作者常用"垃圾回收"。
从某种意义上说，这是我最熟悉的东西之一。GC问题源自lisp和其他函数式语言的实现。我80年代就做过GC算法，后来也一直关注这个问题，对这一领域的情况很熟。在我国最早接触这方面人们一直将其翻译为“废料收集”。后来由于面向对象的出现，GC又成为许多实践工作者关心的事情，又出现了将garbage翻译为“垃圾”的情况。
将garbage翻译为“废料”正是取日常语汇“废品回收”、“废物利用”之义，我觉得很好，恰如其分。翻译为“垃圾”强调的是废弃物，就没有上面这种意思了。我这样说，完全没有将“废料收集”誉为“经典”或者“正统”之意，我从来没想过要去做某种卫道士。我只是想告诉朋友们一些可能他们不了解的情况。“废料收集”已经在许多人那里使用了20年以上，我使用它完全是习惯，也觉得它不是垃圾。
6）smart pointer。我认为应该译为“灵巧指针”，这也是从其他技术领域学来的。我们看到过 smart tools（灵巧工具），smart bomb（灵巧炸弹）等等。常见的另一翻译方式是将其译为“智能指针”，实在令人无法接受。称一个指针“灵巧”也就足够了。对这样一种简单的类似指针的机制，只因为它们稍微多做了一点事情，就说它有“智能”。这能算是智能吗？实在是过分夸大其词，也是对智能的蔑视，对“智能是什么”的过分联想。
计算机领域（也与C++有关）也有一些特别难翻译的词汇。包括：
bind：目前的主要译法有“约束”和“绑定”（还有译为“联编”，这个译法太局限，在许多地方根本无法使用）。这两个译法大约都是从80年代初开始使用。前者由北京大学吴允曾、马希文等先生倡导，后者好像出自科学院计算所。前者取意义，后者希望在意义和发音上都有所获。我个人不喜欢“绑定”，主要是觉得这个词不像技术词汇。“约束”在意义上很合适，但这个中文词使用得太多（无论是作为专业用语还是作为非专业用语），因此也有缺陷。
采用“绑定”的问题还在于英文文献中大量出现 bind 的派生词汇，如 bound、binding、unbinding、unbound 等等，按照原意可能应分别译为“被绑（或‘受绑’）”、“上绑”“松绑”“未绑”等等。不知人们看后有什么感受，我立即想到的是“绑匪”，不觉得它们不像技术术语。采用约束，可以译为“受约”，“建约”，“解约”等等。
override：目前一般译为“覆盖”。这一译法也不很太合适，但目前尚未看到更好的译法。另一种可见译法是“改写”，这一译法的缺陷更明显。override 指某一定义、描述在一个局部范围中取代了原先已经有的更全局的定义。如果我们说局部定义“改写”了全局定义，那么到底改了没有？当然，实际上，局部定义根本不会改写全局定义。它只是引进了一个新定义，这个新定义在该局部中有效，遮蔽了全局定义。在这个局部定义的作用范围之外，原有全局定义仍然有效，根本就没有被改变过。
技术词汇的选择还是可以讨论的。由于这个领域并不太老，所用词汇也还没有收敛，“标准术语”最好是某个能恰如其分地描述有关情况的中文词，能够很好地反映原术语的意义，而又比较符合中文构词习惯。上面只是我的一些认识，它们说服了我。当然，如果存在更好的理由，我也可以改变这些看法。“用的人多”并不一定是“更好的理由”，当然它是最值得重视的理由之一。也正因为此，我在绝大部分情况下都采用了一般人的用法。
| 本页由裘宗燕建立和维护，保留所有权利。
这里的材料可自由地用于个人学习或普通教学活动。其他方式的使用应事先得到作者书面认可。 |
