CLR一书译者（PART III和Part V）对Renart勘误的回应

下面是针对 China-pub 上 Renart 之前的“《CLR via C#》中文版民间勘误”做出的回应。

首先非常感谢 Renart 花精力给出那个勘误，相信对原来的译本是一个很好的补充。下面是

我这边请张杰良就第三部分（13-17）和第五部分（30-78）的勘误给出了说明。

在回应中，如果表示接受 Renart 的意见但觉得也许还可以有另外的表达方式，则给出了另

外的译法，主要是让更方便读者从不同角度去理解。如果表示不同意 Renart 的意见，则给

出了原因以及修改后的译法。

注：为了读者方便参考，对于其他部分（第一、二、四部分）Renart 的勘误也一并在此列

出，但未予以回应。

1．[位置]：90 页-92 页。

[类型]：印刷错误。

[说明]：图 4.2 与图 4.3 应该互换。图 4.4 应该使用图 4.5 中的图。而图 4.5 应该使用原图

4.5 并在其基础上作如下修改：在线程堆栈中“ [返回地址]”的下方再添两项，依次为

“length(Int 32)”和“tally(Int 32)”，并在这两项的右边注明“M2 局部变量”。

2．[位置]：131 页 10 行。

[类型]：翻译错误。

[译文原文]：“从友元程序集中访问上述程序集中的 internal 类型没有什么价值。”

[英文原文]：“ Accessing the above assembly's internal types from a friend assembly is

trivial.”

[类型]：翻译错误。

[译文原文]：“尽管编程语言的编译器忽略可访问性的检查，但是在运行时检验 IL 代码确

[英文原文]：“ Verifying the IL code ensures that a referenced member's accessibility is

下，所引用成员的可访问性在运行时也能得以信守。

4．[位置]：134 页倒数 8 行。

[类型]：翻译错误。

[译文原文]：“而且有一程序开发人员在没有使用源代码控制方法校验类型定义的情况下对

源代码进行了签出。”

[英文原文]：“ and a programmer checks it out of source control to make changes.”

[评论]：译者自以为是地添加了一大堆自己的想法，恐怕没有人会看得懂他倒底是什么意思。

[建议译文]：“有一个程序员将其从源代码控制工具中签出以进行修改”。

----- 《CLR via C#》中文版民间勘误（二） -----

5．[位置]：134 页倒数 3 行至 135 页 5 行。

[类型]：翻译错误

[说明]：“代码拆分器（ Code splitter）”应为“代码生成器（ Code spitter）”。“这些源代码文

件中包含可以直接用于构建这些类型的项目的模板（原文：These source code files contain

templates that give you a head start at building these kinds of projects）”可译“这些源代码文件中

包含了一些模板，它们让你在构建这类项目时享有一个轻松的开始（说明：指有些事情代

器”。“事实是（原文：historically）”应译“先前的版本中，”。“以 Visual Studio 2005 为例

（原文：Starting with Visual Studio 2005）”可译“在 Visual Studio 2005 中”。另，“以 Visual

Studio 2005 为例，”这一句后的一句是“创建新的项目时”。根据作者自己提供的勘误，应该

是“创建 Windows 窗体、Web 窗体和用户控件等的时候”。

[类型]： 翻译错误。

答案就是因为 C#的工作组决定 JIT 编译器应生成验证所使用的对象的代码，以确定调用不

为 null。”

[建议译文]：当然，问题在于，为什么 C#编译器不直接生成 call 指令得了呢？答案是，因

null。

7．[位置]：140 页倒数 9 行。

[类型]：翻译错误。

[译文原文]：“而且组件对于不同的时间进度表其版本也不同。”

[英文原文]：“ and components tend to version with different schedules”

[建议译文]：而且这些组件的版本发布一般都基于不同的日程安排。

[类型]：翻译错误。

[译文原文]：“如果类最初是密封的，将来就无需破坏兼容性将类改变成非密封的。

[英文原文]：“ When a class is originally sealed, it can change to unsealed in the future without

breaking compatibility.”

[建议译文]：如果类原来是密封的，将来把它改为非密封的并不会破坏兼容性。

----- 《CLR via C#》中文版民间勘误（三） -----

9．[位置]：141 页 5 行。

[类型]：翻译错误。

[译文原文]：“另外，如果非密封的类定义了非密封的虚方法，那就必须在新版本的类中保

存虚方法的自定义调用，否则将来可能会破坏派生类的兼容性。

[英文原文]：“ In addition, if the unsealed class defines any unsealed virtual methods, ordering of

the virtual method calls must be maintained with new versions or there is the potential of breaking

derived types in the future.”

能否请译者出来解释一下？这句话中“ordering”一词令人费解，我也说不准它倒底是什么意

10．[位置]：141 页 9 行。

[类型]：翻译错误。

[译文原文]：“但是，如果 JIT 编译器通过使用密封类将调用看成虚方法，……”

…”

[建议译文]：但是，如果看到一个使用密封类型对虚方法的调用……

11．[位置]：141 页倒数 2 行。

[类型]：翻译错误。

[译文原文]：“这将允许基类改变它不影响派生类的观点。”

[英文原文 ]：“ This would allow the base class to change with the knowledge that it will not

[建议译文]：这样一来，因为知道不会影响到派生类，所以可以放心地对基类进行修改。

12．[位置]：150 页倒数 17 行。

[译文原文]：“当某个字段是引用类型，并且该字段标记为 readonly 时，它就是不可改变的

引用本身，而不是它所引用的对象。

----- 《CLR via C#》中文版民间勘误（四） -----

13．[位置]：174 页第 8 章第 8 节第一行。

[译文原文]：声明方法的参数类型时，应尽可能地指定最弱的类型，并且最好在基类上定

[英文原文]：“ When declaring a method's parameter types, you should specify the weakest type

possible, preferring interfaces over base classes.”

classes”这句话的确令人费解。从后文来看，我怀疑此处是作者的笔误，把“and”写成“over”

了。这一点欢迎大家指教。

[建议译文]：声明方法的参数类型时，应指定尽可能弱的类型，接口比基类更好。

说明：基本同意

修改为：

当声明方法的参数类型时，应尽可能地指定最弱的类型，最好是接口类型，而不是基类类

型。

14．[位置]：174 页倒数 7 行。

[类型]：翻译不当。

[译文原文]：“从反面（ flip side）来讲，通常情况下，最好尽量将方法的返回类型声明为

最强的类型（尽量不要限于一个具体的类型）”。

[英文原文]：“ On the flip side, it is usually best to declare a method's return type by using the

strongest type possible (trying not to commit yourself to a specific type).”

本意，括号里的话应该是从方法的调用者的角度来说的，意思是指如果把方法的返回类型

指定为弱类型，那么对于调用者来说，使用这个返回值的时候就受到很大限制，就象是把

话说满了，以后想改都不行了。这样理解的话，翻译的时候就应该适量加入一些内容。当

[建议译文]：另一方面，方法的返回类型一般应该声明为尽量强的类型（以免在调用代码

说明：不接受，但可以参考，如果觉得不太好理解的话，或者怕引起误解的话，可以加入

修改为：

另一方面，通常情况下，最好尽量将方法的返回类型声明为最强的类型（尽量不要局限于

一个特定的类型）。（译注：以免在调用代码中使用方法的返回值时局限于一个特定的类

[建议译文]：属性不能重载，也即，不能定义两个类型不同而名称却相同的属性。

说明：不同意，最终意思虽然相同，但是强调的重点不一样了。