happmaoo
- 浏览: 4604496 次
- 性别:
- 来自: 杭州
-
最新评论
-
netkongjian：
不错的软件知识，感谢分享！
软件加密方式 -
norce：
效果不错~
JS实现图片幻灯片效果 -
zxbear：
链接已失效
《jQuery基础教程：第2版》PDF -
架构师：
在技术领域方面Java还是世界上最好的，而且有很多第三方控件的 ...
专访：Ruby能否成为第二个Java -
freddie：
如何拖动表格边框调整行高和列宽？
可编辑的表格(JavaScript)
<iframe align="top" marginwidth="0" marginheight="0" src="http://www.zealware.com/46860.html" frameborder="0" width="468" scrolling="no" height="60"></iframe>
[类型]：印刷错误。
[说明]：图4.2与图4.3应该互换。图4.4应该使用图4.5中的图。而图4.5应该使用原图4.5并在其基础上作如下修改：在线程堆栈中“[返回地址]”的下方再添两项，依次为“length(Int 32)”和“tally(Int 32)”，并在这两项的右边注明“M2局部变量”。
6．[位置]：139页3行。
[类型]： 翻译错误。
[译文原文]：“当然，问题在于，为什么C#编译器只生成call指令，而不是其他指令呢？答案就是因为C#的工作组决定JIT编译器应生成验证所使用的对象的代码，以确定调用不为null。”
[英文原文]：“Of course, the question is, why didn't the C# compiler simply emit the call instruction instead? The answer is because the C# team decided that the JIT compiler should generate code to verify that the object being used to make the call is not null.”
[建议译文]：当然，问题在于，为什么C#编译器不直接生成call指令得了呢？答案是，因为C#工作组决定JIT编译器应该生成一些验证代码，以确保用于执行这一调用的对象不是null。
7．[位置]：140页倒数9行。
[类型]：翻译错误。
[译文原文]：“而且组件对于不同的时间进度表其版本也不同。”
[英文原文]：“and components tend to version with different schedules”
[建议译文]：而且这些组件的版本发布一般都基于不同的日程安排。
8．[位置]：141页3行。
[类型]：翻译错误。
[译文原文]：“如果类最初是密封的，将来就无需破坏兼容性将类改变成非密封的。
[英文原文]：“When a class is originally sealed, it can change to unsealed in the future without breaking compatibility.”
[建议译文]：如果类原来是密封的，将来把它改为非密封的并不会破坏兼容性。
10．[位置]：141页9行。
[类型]：翻译错误。
[译文原文]：“但是，如果JIT编译器通过使用密封类将调用看成虚方法，……”
[英文原文]：“However, if the JIT compiler sees a call to a virtual method using a sealed type, …”
[建议译文]：但是，如果看到一个使用密封类型对虚方法的调用……
11．[位置]：141页倒数2行。
[类型]：翻译错误。
[译文原文]：“这将允许基类改变它不影响派生类的观点。”
[英文原文]：“This would allow the base class to change with the knowledge that it will not impact a derived class.”
[建议译文]：这样一来，因为知道不会影响到派生类，所以可以放心地对基类进行修改。
12．[位置]：150页倒数17行。
[类型]：翻译错误。
[译文原文]：“当某个字段是引用类型，并且该字段标记为readonly时，它就是不可改变的引用，而不是字段所引用的对象。”
[英文原文]：“When a field is of a reference type and the field is marked as readonly, it is the reference that is immutable, not the object that the field refers to.”
[建议译文]：如果一个字段属于引用类型，并且被标记为readonly时，不可改变的是这个引用本身，而不是它所引用的对象。
下面是针对China-pub上Renart之前的“《CLR via C#》中文版民间勘误”做出的回应。
首先非常感谢Renart花精力给出那个勘误，相信对原来的译本是一个很好的补充。下面是我这边请张杰良就第三部分（13-17）和第五部分（30-78）的勘误给出了说明。
在回应中，如果表示接受Renart的意见但觉得也许还可以有另外的表达方式，则给出了另外的译法，主要是让更方便读者从不同角度去理解。如果表示不同意Renart的意见，则给出了原因以及修改后的译法。
注：为了读者方便参考，对于其他部分（第一、二、四部分）Renart的勘误也一并在此列出，但未予以回应。
———————————————————————————————————————
----- 《CLR via C#》中文版民间勘误（一）
对每一个翻译问题，我都提供了自己的建议译法（第9条是个例外），其中有一些可能不是很理想，欢迎批评指正。这几条可能需要首先请各位分析一下：第9、13、18、67和74条。
下面是勘误内容：
1．[位置]：90页-92页。
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.”
[类型]：翻译错误。
[译文原文]：“从友元程序集中访问上述程序集中的internal类型没有什么价值。”
[英文原文]：“Accessing the above assembly's internal types from a friend assembly is trivial.”
[建议译文]：从友元程序集中访问上述程序集中的internal类型只是举手之劳。
3．[位置]：132页倒数8行。
[类型]：翻译错误。
[译文原文]：“尽管编程语言的编译器忽略可访问性的检查，但是在运行时检验IL代码确保已引用成员的的可访问性是值得的，”
[英文原文]：“Verifying the IL code ensures that a referenced member's accessibility is properly honored at run time, even if a language compiler ignored checking the accessibility.”
[建议译文]：对IL代码的验证确保了，即便在编程语言的编译器忽略可访问性检查的情况下，所引用成员的可访问性在运行时也能得以信守。
[译文原文]：“尽管编程语言的编译器忽略可访问性的检查，但是在运行时检验IL代码确保已引用成员的的可访问性是值得的，”
[英文原文]：“Verifying the IL code ensures that a referenced member's accessibility is properly honored at run time, even if a language compiler ignored checking the accessibility.”
[建议译文]：对IL代码的验证确保了，即便在编程语言的编译器忽略可访问性检查的情况下，所引用成员的可访问性在运行时也能得以信守。
4．[位置]：134页倒数8行。
[类型]：翻译错误。
[译文原文]：“而且有一程序开发人员在没有使用源代码控制方法校验类型定义的情况下对源代码进行了签出。”
[英文原文]：“and a programmer checks it out of source control to make changes.”
[评论]：译者自以为是地添加了一大堆自己的想法，恐怕没有人会看得懂他倒底是什么意思。
[建议译文]：“有一个程序员将其从源代码控制工具中签出以进行修改”。
[类型]：翻译错误。
[译文原文]：“而且有一程序开发人员在没有使用源代码控制方法校验类型定义的情况下对源代码进行了签出。”
[英文原文]：“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）”可译“这些源代码文件中包含了一些模板，它们让你在构建这类项目时享有一个轻松的开始（说明：指有些事情代码生成器已经先替你作好了，你只要在此基础上进行工作就行，因此相对于没有代码生成器的帮助的情况，你就拥有‘head start’）”。“Visual Studio设计中心”应译“Visual Studio设计器”。“事实是（原文：historically）”应译“先前的版本中，”。“以Visual Studio 2005为例（原文：Starting with Visual Studio 2005）”可译“在 Visual Studio 2005中”。另，“以Visual Studio 2005为例，”这一句后的一句是“创建新的项目时”。根据作者自己提供的勘误，应该是“创建Windows窗体、Web窗体和用户控件等的时候”。
[类型]：翻译错误
[说明]：“代码拆分器（Code splitter）”应为“代码生成器（Code spitter）”。“这些源代码文件中包含可以直接用于构建这些类型的项目的模板（原文：These source code files contain templates that give you a head start at building these kinds of projects）”可译“这些源代码文件中包含了一些模板，它们让你在构建这类项目时享有一个轻松的开始（说明：指有些事情代码生成器已经先替你作好了，你只要在此基础上进行工作就行，因此相对于没有代码生成器的帮助的情况，你就拥有‘head start’）”。“Visual Studio设计中心”应译“Visual Studio设计器”。“事实是（原文：historically）”应译“先前的版本中，”。“以Visual Studio 2005为例（原文：Starting with Visual Studio 2005）”可译“在 Visual Studio 2005中”。另，“以Visual Studio 2005为例，”这一句后的一句是“创建新的项目时”。根据作者自己提供的勘误，应该是“创建Windows窗体、Web窗体和用户控件等的时候”。
6．[位置]：139页3行。
[类型]： 翻译错误。
[译文原文]：“当然，问题在于，为什么C#编译器只生成call指令，而不是其他指令呢？答案就是因为C#的工作组决定JIT编译器应生成验证所使用的对象的代码，以确定调用不为null。”
[英文原文]：“Of course, the question is, why didn't the C# compiler simply emit the call instruction instead? The answer is because the C# team decided that the JIT compiler should generate code to verify that the object being used to make the call is not null.”
[建议译文]：当然，问题在于，为什么C#编译器不直接生成call指令得了呢？答案是，因为C#工作组决定JIT编译器应该生成一些验证代码，以确保用于执行这一调用的对象不是null。
7．[位置]：140页倒数9行。
[类型]：翻译错误。
[译文原文]：“而且组件对于不同的时间进度表其版本也不同。”
[英文原文]：“and components tend to version with different schedules”
[建议译文]：而且这些组件的版本发布一般都基于不同的日程安排。
8．[位置]：141页3行。
[类型]：翻译错误。
[译文原文]：“如果类最初是密封的，将来就无需破坏兼容性将类改变成非密封的。
[英文原文]：“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”一词令人费解，我也说不准它倒底是什么意思。请各位指教。
[类型]：翻译错误。
[译文原文]：“另外，如果非密封的类定义了非密封的虚方法，那就必须在新版本的类中保存虚方法的自定义调用，否则将来可能会破坏派生类的兼容性。
[英文原文]：“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编译器通过使用密封类将调用看成虚方法，……”
[英文原文]：“However, if the JIT compiler sees a call to a virtual method using a sealed type, …”
[建议译文]：但是，如果看到一个使用密封类型对虚方法的调用……
11．[位置]：141页倒数2行。
[类型]：翻译错误。
[译文原文]：“这将允许基类改变它不影响派生类的观点。”
[英文原文]：“This would allow the base class to change with the knowledge that it will not impact a derived class.”
[建议译文]：这样一来，因为知道不会影响到派生类，所以可以放心地对基类进行修改。
12．[位置]：150页倒数17行。
[类型]：翻译错误。
[译文原文]：“当某个字段是引用类型，并且该字段标记为readonly时，它就是不可改变的引用，而不是字段所引用的对象。”
[英文原文]：“When a field is of a reference type and the field is marked as readonly, it is the reference that is immutable, not the object that the field refers to.”
[建议译文]：如果一个字段属于引用类型，并且被标记为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.”
[评论]：“最好在基类上定义接口”这句话倒底是什么意思？“preferring interfaces over base classes”这句话的确令人费解。从后文来看，我怀疑此处是作者的笔误，把“and”写成“over”了。这一点欢迎大家指教。
[建议译文]：声明方法的参数类型时，应指定尽可能弱的类型，接口比基类更好。
[类型]：翻译错误。
[译文原文]：声明方法的参数类型时，应尽可能地指定最弱的类型，并且最好在基类上定义接口。
[英文原文]：“When declaring a method's parameter types, you should specify the weakest type possible, preferring interfaces over base classes.”
[评论]：“最好在基类上定义接口”这句话倒底是什么意思？“preferring interfaces over base 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).”
[评论]：“尽量不要限于一个具体的类型”这种译法在此场合让人越看越不明白。揣摩作才的本意，括号里的话应该是从方法的调用者的角度来说的，意思是指如果把方法的返回类型指定为弱类型，那么对于调用者来说，使用这个返回值的时候就受到很大限制，就象是把话说满了，以后想改都不行了。这样理解的话，翻译的时候就应该适量加入一些内容。当然，这种理解只是我个人的看法，欢迎大家指教。
[建议译文]：另一方面，方法的返回类型一般应该声明为尽量强的类型（以免在调用代码中使用方法的返回值时被局限于一个特定的类型）。
[类型]：翻译不当。
[译文原文]：“从反面（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).”
[评论]：“尽量不要限于一个具体的类型”这种译法在此场合让人越看越不明白。揣摩作才的本意，括号里的话应该是从方法的调用者的角度来说的，意思是指如果把方法的返回类型指定为弱类型，那么对于调用者来说，使用这个返回值的时候就受到很大限制，就象是把话说满了，以后想改都不行了。这样理解的话，翻译的时候就应该适量加入一些内容。当然，这种理解只是我个人的看法，欢迎大家指教。
[建议译文]：另一方面，方法的返回类型一般应该声明为尽量强的类型（以免在调用代码中使用方法的返回值时被局限于一个特定的类型）。
说明：不接受，但可以参考，如果觉得不太好理解的话，或者怕引起误解的话，可以加入一个译注。但是这句话从上下文中可以理解出，后面有解释语句。
修改为：
另一方面，通常情况下，最好尽量将方法的返回类型声明为最强的类型（尽量不要局限于一个特定的类型）。（译注：以免在调用代码中使用方法的返回值时局限于一个特定的类型，从而失去灵活性。）
15．[位置]：178页倒数19行。
[类型]：翻译不当。
[译文原文]：“属性不能被重载，也就是说，如果其类型不同，两个属性可以同名。”
[英文原文]：“It isn't possible to overload properties(that is, have two properties with the same name if their types are different).”
[建议译文]：属性不能重载，也即，不能定义两个类型不同而名称却相同的属性。
[类型]：翻译不当。
[译文原文]：“属性不能被重载，也就是说，如果其类型不同，两个属性可以同名。”
[英文原文]：“It isn't possible to overload properties(that is, have two properties with the same name if their types are different).”
[建议译文]：属性不能重载，也即，不能定义两个类型不同而名称却相同的属性。
说明：不同意，最终意思虽然相同，但是强调的重点不一样了。
16．[位置]：178页倒数16行。
[类型]：翻译不当。
[译文原文]：“通过属性的get和set方法操作类型内定义的私有字段，这种做法也十分常见。私有字段通常称为后备字段（backing field），但是get和set方法没有必要访问后备字段。”
[英文原文]：“It's also quite common for the property's get/set methods to manipulate a private field defined within the type. This field is commonly referred to as the backing field. The get and set methods don't have to access a backing field, however.”
[建议译文]：通过属性的get和set方法操作类型内定义的私有字段，这种做法也十分常见。该私有字段通常称为后台字段（backing field）。但是，get和set方法也并不是非得访问一个后台字段不可。
[类型]：翻译不当。
[译文原文]：“通过属性的get和set方法操作类型内定义的私有字段，这种做法也十分常见。私有字段通常称为后备字段（backing field），但是get和set方法没有必要访问后备字段。”
[英文原文]：“It's also quite common for the property's get/set methods to manipulate a private field defined within the type. This field is commonly referred to as the backing field. The get and set methods don't have to access a backing field, however.”
[建议译文]：通过属性的get和set方法操作类型内定义的私有字段，这种做法也十分常见。该私有字段通常称为后台字段（backing field）。但是，get和set方法也并不是非得访问一个后台字段不可。
说明：给出的[译文原文]与交稿内容不符。
原译文：通过属性的get和set方法操作类型内定义的私有字段的做法也十分常见。私有字段通常作为后备字段（backing field）引用，但是get和set方法并非必须要访问后备字段。
----- 《CLR via C#》中文版民间勘误（五） -----
17．[位置]：182页14行。
[类型]：翻译错误。
[译文原文]：“创建一个索引器然后在相关的数组中查询数值的做法十分常见。”
[英文原文]：“It's quite common to create an indexer to look up values in an associative array.”
[评论]：“associative array”是一个术语。普通数组是通过一个整型的索引值来定位元素，而关联数组则可通过字符串等其它类型的索引值来定位元素。
[建议译文]：创建一个索引器来在关联数组中查找值的做法很常见。
[类型]：翻译错误。
[译文原文]：“创建一个索引器然后在相关的数组中查询数值的做法十分常见。”
[英文原文]：“It's quite common to create an indexer to look up values in an associative array.”
[评论]：“associative array”是一个术语。普通数组是通过一个整型的索引值来定位元素，而关联数组则可通过字符串等其它类型的索引值来定位元素。
[建议译文]：创建一个索引器来在关联数组中查找值的做法很常见。
说明：接受
18．[位置]：217页第11章第3节第4段。
[类型]：翻译不当。
[译文原文]：“StringBuilder的String方法返回的String绝对不能更改。所以，如果调用一个方法来修改StringBuilder维护的字符串字段，StringBuilder的方法就会收到信息，知道已在字符串字段上调用了ToString，所以会在内部创建并使用一个新的字符数组，让你对这个新的数组执行操作，而不影响之前的ToString调用返回的字符串”。
[英文原文]：“The String returned from StringBuilder's ToString method must not be changed. So if you ever call a method that attempts to modify the string field maintained by the StringBuilder, the StringBuilder's methods will have the information that ToString was called on the string field and they will internally create and use a new character array, allowing you to perform manipulations without affecting the string returned by the previous call to ToString.”
[评论]：我认为作者本人的表达就有些不清楚（包括一些语法问题）。这种情况下，翻译如果强调绝对忠实于原文，恐怕反不利于读者的理解。作者第一句话中所说的“更改”，是指因调用StringBuilder的方法而对（先前调用它的ToString方法得到的）字符串的更改，而不是调用Sting类的方法而对（先前调用StringBuilder的ToString方法得到的）字符串的更改。假如是后者，因为String类的方法本来就不会在原字符串身上进行更改，而是会把更改结果作为一个新字符串返回，所以这样说毫无意义，作者不可能是这种意思。同样的道理，作者在第二句话中所说的“方法”也应该是StringBuilder类的方法而不是String类的方法。因此，作者在这一段的本意，应该是说：在对StringBuilder类实例调用过ToString方法得到一个字符串（后称s）之后，再调用StringBuilder类的一些会导致其内部维护的字符串发生改变的方法的话，这个改变不会体现在s身上。基于这样的认识，翻译的时候必须补充一些内容。当然，这个问题也欢迎大家指教。
[建议译文]：StringBuilder的ToString方法返回的字符串不能被（StringBuilder的方法）更改。如果在调用过ToString方法后，再调用StringBuilder的会修改其维护的字符串字段的方法，那么方法会知道之前ToString已经被调用过，因此它将在内部另建并使用一个新的字符数组，这使你能够修改StringBuilder维护的字符串，同时又不影响先前调用ToString时返回的字符串。
[类型]：翻译不当。
[译文原文]：“StringBuilder的String方法返回的String绝对不能更改。所以，如果调用一个方法来修改StringBuilder维护的字符串字段，StringBuilder的方法就会收到信息，知道已在字符串字段上调用了ToString，所以会在内部创建并使用一个新的字符数组，让你对这个新的数组执行操作，而不影响之前的ToString调用返回的字符串”。
[英文原文]：“The String returned from StringBuilder's ToString method must not be changed. So if you ever call a method that attempts to modify the string field maintained by the StringBuilder, the StringBuilder's methods will have the information that ToString was called on the string field and they will internally create and use a new character array, allowing you to perform manipulations without affecting the string returned by the previous call to ToString.”
[评论]：我认为作者本人的表达就有些不清楚（包括一些语法问题）。这种情况下，翻译如果强调绝对忠实于原文，恐怕反不利于读者的理解。作者第一句话中所说的“更改”，是指因调用StringBuilder的方法而对（先前调用它的ToString方法得到的）字符串的更改，而不是调用Sting类的方法而对（先前调用StringBuilder的ToString方法得到的）字符串的更改。假如是后者，因为String类的方法本来就不会在原字符串身上进行更改，而是会把更改结果作为一个新字符串返回，所以这样说毫无意义，作者不可能是这种意思。同样的道理，作者在第二句话中所说的“方法”也应该是StringBuilder类的方法而不是String类的方法。因此，作者在这一段的本意，应该是说：在对StringBuilder类实例调用过ToString方法得到一个字符串（后称s）之后，再调用StringBuilder类的一些会导致其内部维护的字符串发生改变的方法的话，这个改变不会体现在s身上。基于这样的认识，翻译的时候必须补充一些内容。当然，这个问题也欢迎大家指教。
[建议译文]：StringBuilder的ToString方法返回的字符串不能被（StringBuilder的方法）更改。如果在调用过ToString方法后，再调用StringBuilder的会修改其维护的字符串字段的方法，那么方法会知道之前ToString已经被调用过，因此它将在内部另建并使用一个新的字符数组，这使你能够修改StringBuilder维护的字符串，同时又不影响先前调用ToString时返回的字符串。
----- 《CLR via C#》中文版民间勘误（六） -----
19．[位置]：257页代码中的Unsafe2DimArrayAccess方法。
[类型]：原著错误。
[说明]：“Int32 dim0Elements = dim0HighIndex – dim0LowIndex;”这句应该改成
“Int32 dim1Elements = dim1HighIndex – dim1LowIndex + 1;”。
“Int32 baseOfDim = x * dim0Elements;”这句应该改成
“Int32 baseOfDim = x * dim1Elements;”。因为从baseOfDim的用途来看，其中原来的“dim0Elements”应该是指第二维的元素个数，因此在前后两句中都应该把其名字中的“0”改为“1”。至于第一句中应该再加上一个数值1的原因，就不必多说了吧。这个错误在作者本人提供的勘误中都还没有指出来。
[类型]：原著错误。
[说明]：“Int32 dim0Elements = dim0HighIndex – dim0LowIndex;”这句应该改成
“Int32 dim1Elements = dim1HighIndex – dim1LowIndex + 1;”。
“Int32 baseOfDim = x * dim0Elements;”这句应该改成
“Int32 baseOfDim = x * dim1Elements;”。因为从baseOfDim的用途来看，其中原来的“dim0Elements”应该是指第二维的元素个数，因此在前后两句中都应该把其名字中的“0”改为“1”。至于第一句中应该再加上一个数值1的原因，就不必多说了吧。这个错误在作者本人提供的勘误中都还没有指出来。
20．[位置]：273页7行。
[类型]：翻译不当。
[译文原文]：“在.NET Framework参考文档中查看一个类型的方法时，列出的是显式接口的方法实现，但没有类型的具体帮助，只能看到接口方法的常规帮助。”
[英文原文]：“When examining the methods for a type in the .NET Framework reference documentation, explicit interface method implementations are listed, but no type-specific help exists; you can just read the general help about the interface methods.”
[建议译文]：在.NET Framework参考文档中查看一个类型的方法时，显式接口方法实现也会列出来，但是没有特定于该类型的（针对显式接口方法实现的）帮助信息，只能读到关于那些接口方法的一般性帮助信息。
[类型]：翻译不当。
[译文原文]：“在.NET Framework参考文档中查看一个类型的方法时，列出的是显式接口的方法实现，但没有类型的具体帮助，只能看到接口方法的常规帮助。”
[英文原文]：“When examining the methods for a type in the .NET Framework reference documentation, explicit interface method implementations are listed, but no type-specific help exists; you can just read the general help about the interface methods.”
[建议译文]：在.NET Framework参考文档中查看一个类型的方法时，显式接口方法实现也会列出来，但是没有特定于该类型的（针对显式接口方法实现的）帮助信息，只能读到关于那些接口方法的一般性帮助信息。
21．[位置]：275页倒19行。
[类型]：翻译错误。
[译文原文]：“通过为基类型提供一个良好的默认实现，然后开始使用能正常工作并通过良好测试一个类型，以后就可以对需要它的地方做出修改。”
[英文原文]：“By providing a base type with a good default implementation, you start off using a type that works and is well tested; you can then modify parts that need modification.”
[评论]：这个错误实在莫名其妙，就算用翻译软件来译也不该出现这样古怪的译法吧。
[建议译文]：通过提供一个具有良好的默认实现的基类，即可用上一个管用的并且已经认真测试过的类型，然后，你可以对需要修改的部分进行修改。
[类型]：翻译错误。
[译文原文]：“通过为基类型提供一个良好的默认实现，然后开始使用能正常工作并通过良好测试一个类型，以后就可以对需要它的地方做出修改。”
[英文原文]：“By providing a base type with a good default implementation, you start off using a type that works and is well tested; you can then modify parts that need modification.”
[评论]：这个错误实在莫名其妙，就算用翻译软件来译也不该出现这样古怪的译法吧。
[建议译文]：通过提供一个具有良好的默认实现的基类，即可用上一个管用的并且已经认真测试过的类型，然后，你可以对需要修改的部分进行修改。
22．[位置]：288页17行。
[类型]：翻译错误。
[译文原文]：“但本来应该像下面这样定义Feedback委托：”
[英文原文]：“However, I could have defined my Feedback delegate as follows:”
[建议译文]：但我本来也可以这样定义Feedback委托
[类型]：翻译错误。
[译文原文]：“但本来应该像下面这样定义Feedback委托：”
[英文原文]：“However, I could have defined my Feedback delegate as follows:”
[建议译文]：但我本来也可以这样定义Feedback委托
----- 《CLR via C#》中文版民间勘误（七） -----
23．[位置]：316页倒数第1段（不计代码）第3行。
[类型]：疑似印刷错误。
[译文原文]：“CLR允许基于类型参数名称或者约束来进行重载。”
[英文原文]：“The CLR doesn't allow overloading based on type parameter names or constraints”
[建议译文]：把“允许”改成“不允许”。
[类型]：疑似印刷错误。
[译文原文]：“CLR允许基于类型参数名称或者约束来进行重载。”
[英文原文]：“The CLR doesn't allow overloading based on type parameter names or constraints”
[建议译文]：把“允许”改成“不允许”。
24．[位置]：317页倒数12行。
[类型]：翻译错误。
[译文原文]：“不需要指定以下特殊的引用类型：”
[英文原文]：“You cannot specify one of the following special reference types:”
[建议译文]：不能指定下列特殊引用类型。
[类型]：翻译错误。
[译文原文]：“不需要指定以下特殊的引用类型：”
[英文原文]：“You cannot specify one of the following special reference types:”
[建议译文]：不能指定下列特殊引用类型。
25．[位置]：318页16行
[类型]：翻译错误。
[译文原文]：“然而，编译器和CLR将任何System.Nullable<t>值类型视为一个特殊类型，而可空的类型不能指定这个约束。”<br>[英文原文]：“However, the compiler and the CLR treat any System.Nullable<t> value type as a special type, and nullable types do not satisfy this constraint.”<br>[建议译文]：然而，编译器和CLR把所有System.Nullable<t>值类型作为特殊类型对待，所以可空类型不能满足这一（struct）约束。</t></t></t>
[类型]：翻译错误。
[译文原文]：“然而，编译器和CLR将任何System.Nullable<t>值类型视为一个特殊类型，而可空的类型不能指定这个约束。”<br>[英文原文]：“However, the compiler and the CLR treat any System.Nullable<t> value type as a special type, and nullable types do not satisfy this constraint.”<br>[建议译文]：然而，编译器和CLR把所有System.Nullable<t>值类型作为特殊类型对待，所以可空类型不能满足这一（struct）约束。</t></t></t>
26．[位置]：330页7行。
[类型]：翻译错误。
[译文原文]：“除此之外，可以使用一个基于零的一维数组，并选择性地将上述类型添加到其中。”
[英文原文]：“In addition, you can use a single dimensional, zero-based array of any of these types.”
[建议译文]：此外，也可使用元素为这些类型的一维零基数组。
[类型]：翻译错误。
[译文原文]：“除此之外，可以使用一个基于零的一维数组，并选择性地将上述类型添加到其中。”
[英文原文]：“In addition, you can use a single dimensional, zero-based array of any of these types.”
[建议译文]：此外，也可使用元素为这些类型的一维零基数组。
----- 《CLR via C#》中文版民间勘误（八） -----
27．[位置]：337页14行。
[类型]：翻译错误。
[译文原文]：“通常，我们可以使用CustomAttributeData类，分析通过Assembly的静态方法ReflectionOnlyLoad（也在第22章讨论）在一个程序集的元数据中加载的属性。”
[英文原文]：“Typically, you'll use the CustomAttributeData class to analyze attributes in metadata for an assembly that is loaded via Assembly's static ReflectionOnlyLoad method(also discussed in Chapter 22).”
[评论]：attribute是通过Assembly.ReflectionOnlyLoad加载到一个程序集的元数据当中去的吗？译者这个错误也犯得太业余了一点吧。
[建议译文]：CustomAttributeData类的典型用法是用于分析一个用Assembly的静态ReflectionOnlyLoad方法（也在第22章讨论）加载的程序集的元数据中的属性。
[类型]：翻译错误。
[译文原文]：“通常，我们可以使用CustomAttributeData类，分析通过Assembly的静态方法ReflectionOnlyLoad（也在第22章讨论）在一个程序集的元数据中加载的属性。”
[英文原文]：“Typically, you'll use the CustomAttributeData class to analyze attributes in metadata for an assembly that is loaded via Assembly's static ReflectionOnlyLoad method(also discussed in Chapter 22).”
[评论]：attribute是通过Assembly.ReflectionOnlyLoad加载到一个程序集的元数据当中去的吗？译者这个错误也犯得太业余了一点吧。
[建议译文]：CustomAttributeData类的典型用法是用于分析一个用Assembly的静态ReflectionOnlyLoad方法（也在第22章讨论）加载的程序集的元数据中的属性。
28．[位置]：337页19行。
[类型]：翻译错误。
[译文原文]：“调用它时，它会返回Ilist<customattributedata>类型的一个对象中，返回由CustomAttributeData对象构成的一个集合。”<br>[英文原文]：“when you call it, it returns a collection of CustomAttributeData objects in an object of type IList<customattributedata>”<br>[建议译文]：调用它时，将返回一个Ilist<customattributedata>类型的对象，其中包含了一批CustomAttributeData类型的对象。</customattributedata></customattributedata></customattributedata>
[类型]：翻译错误。
[译文原文]：“调用它时，它会返回Ilist<customattributedata>类型的一个对象中，返回由CustomAttributeData对象构成的一个集合。”<br>[英文原文]：“when you call it, it returns a collection of CustomAttributeData objects in an object of type IList<customattributedata>”<br>[建议译文]：调用它时，将返回一个Ilist<customattributedata>类型的对象，其中包含了一批CustomAttributeData类型的对象。</customattributedata></customattributedata></customattributedata>
29．[位置]：344页倒数3行。
[类型]：翻译错误。
[译文原文]：“但并不是一个理想的结果，因为方法现在是作为一个非空的值传递的，即使Nullable<int32>变量逻辑上包含null值。”<br>[英文原文]：“This is not ideal because the method is now being passed a non-null value even though the Nullable<int32> variable logically contained the value of null.”<br>[建议译文]：这种处理并不理想，因为尽管那个Nullable<int32>变量逻辑上包含着null值，现在传给方法的却是一个非空值。</int32></int32></int32>
[类型]：翻译错误。
[译文原文]：“但并不是一个理想的结果，因为方法现在是作为一个非空的值传递的，即使Nullable<int32>变量逻辑上包含null值。”<br>[英文原文]：“This is not ideal because the method is now being passed a non-null value even though the Nullable<int32> variable logically contained the value of null.”<br>[建议译文]：这种处理并不理想，因为尽管那个Nullable<int32>变量逻辑上包含着null值，现在传给方法的却是一个非空值。</int32></int32></int32>
30．[位置]：355页倒数8行。
[类型]：翻译错误。
[译文原文]：“所有未抛出的异常将被封装入一个System.Runtime.CompilerServices.RuntimeWrappedException。”
[英文原文]：“All non-exceptions thrown will be wrapped in a System.Runtime.CompilerServices.RuntimeWrappedException.”
[建议译文]：抛出的各类“非异常”（non-exception，指一个并非exception类或其派生类实例的对象）都会用一个System.Runtime.CompilerServices.RuntimeWrappedException类型对象加以包装。
[类型]：翻译错误。
[译文原文]：“所有未抛出的异常将被封装入一个System.Runtime.CompilerServices.RuntimeWrappedException。”
[英文原文]：“All non-exceptions thrown will be wrapped in a System.Runtime.CompilerServices.RuntimeWrappedException.”
[建议译文]：抛出的各类“非异常”（non-exception，指一个并非exception类或其派生类实例的对象）都会用一个System.Runtime.CompilerServices.RuntimeWrappedException类型对象加以包装。
说明：上交译文中本句没有翻译，保留的是英文原文
----- 《CLR via C#》中文版民间勘误（九） -----
31．[位置]：355页倒数2行。
[类型]：翻译错误。
[译文原文]：“相反，CLR不包装不符合CLS的对象，而且仅当catch块没有指定任何类型时才调用我们自己的代码。”
[英文原文]：“And instead, the CLR should unwrap the non-CLS-compliant object and call your code only if you have a catch block that doesn't specify any type at all.”
[建议译文]：作为替代措施，仅当存在一个根本未指定任何类型的catch块时，CLR才应该解开对那个非CLS兼容的对象的包装并调用你的代码。
[类型]：翻译错误。
[译文原文]：“相反，CLR不包装不符合CLS的对象，而且仅当catch块没有指定任何类型时才调用我们自己的代码。”
[英文原文]：“And instead, the CLR should unwrap the non-CLS-compliant object and call your code only if you have a catch block that doesn't specify any type at all.”
[建议译文]：作为替代措施，仅当存在一个根本未指定任何类型的catch块时，CLR才应该解开对那个非CLS兼容的对象的包装并调用你的代码。
说明：接受
修改为：
作为替代措施，仅当存在一个根本未指定任何类型的catch块时，CLR才会解开不符合CLS的对象并调用代码。
32．[位置]：365页倒数16行。
[类型]：翻译不当。
[译文原文]：“记住，Debug.Assert的调用在程序集的发行版本中不存在，但是异常仍然被抛出……程序集不应使用Debug.Assert调用来确保另一程序集中的代码正确调用方法，但异常可以这样使用。”
[英文原文]：“Remember that Debug.Assert calls vanish out of the code for a release build, whereas exceptions will still get thrown … an assembly should not use Debug.Assert calls to ensure that code in another assembly is calling a method correctly; use exceptions for this.”
[建议译文]：记住，在程序集的release生成版本的代码中不会再有对Debug.Assert的调用，但依然会有异常被抛出……程序集如要确保一个方法能被另一程序集的代码正确地调用，应该使用异常，而不是Debug.Assert调用。
[类型]：翻译不当。
[译文原文]：“记住，Debug.Assert的调用在程序集的发行版本中不存在，但是异常仍然被抛出……程序集不应使用Debug.Assert调用来确保另一程序集中的代码正确调用方法，但异常可以这样使用。”
[英文原文]：“Remember that Debug.Assert calls vanish out of the code for a release build, whereas exceptions will still get thrown … an assembly should not use Debug.Assert calls to ensure that code in another assembly is calling a method correctly; use exceptions for this.”
[建议译文]：记住，在程序集的release生成版本的代码中不会再有对Debug.Assert的调用，但依然会有异常被抛出……程序集如要确保一个方法能被另一程序集的代码正确地调用，应该使用异常，而不是Debug.Assert调用。
说明：接受
修改为：
记住，Debug.Assert的调用在程序集的发行版本代码中已不存在，但是异常仍然被抛出……程序集不应再使用Debug.Assert调用来确保另一程序集中的代码正确调用方法，而应该使用异常。
33．[位置]：371页2行。
[类型]：翻译错误。
[译文原文]：“在进入该公共方法后，代码首先要检查x是否为0，如果x为0，方法就抛出一个ArgumentOutOfRangeException异常。每次执行方法时都要进行一次这样的检查，”
[英文原文]：“Upon entry into this public method, code could check to see whether x is 0, and if it is, throw an ArgumentOutOfRangeException exception. This check would be performed every time,”
[评论]：虚拟语气没有译出来。
[建议译文]：本来也可以在该公共方法的入口处让代码检查x是否为0，并在其为0的情况抛出一个ArgumentOutOfRangeException异常。这样一来，检查会在每次调用方法时都被执行。
[类型]：翻译错误。
[译文原文]：“在进入该公共方法后，代码首先要检查x是否为0，如果x为0，方法就抛出一个ArgumentOutOfRangeException异常。每次执行方法时都要进行一次这样的检查，”
[英文原文]：“Upon entry into this public method, code could check to see whether x is 0, and if it is, throw an ArgumentOutOfRangeException exception. This check would be performed every time,”
[评论]：虚拟语气没有译出来。
[建议译文]：本来也可以在该公共方法的入口处让代码检查x是否为0，并在其为0的情况抛出一个ArgumentOutOfRangeException异常。这样一来，检查会在每次调用方法时都被执行。
说明：接受
34．[位置]：371页18行。
[类型]：翻译错误。
[译文原文]：“我们应该为调用堆栈中居于较高层次的代码提供机会，使它们不仅能够捕获System.Exception异常，而且还能够捕获其他一些用作基础类型的较具体的异常。”
[英文原文]：“Give the code higher up the call stack a chance to catch System.Exception or some other exception that's a base type for more specific exceptions.”
[建议译文]：把捕获System.Exception或别的身为那些更具体的异常的基类型的异常的机会让给调用堆栈中更高层的代码吧。
[译文原文]：“我们应该为调用堆栈中居于较高层次的代码提供机会，使它们不仅能够捕获System.Exception异常，而且还能够捕获其他一些用作基础类型的较具体的异常。”
[英文原文]：“Give the code higher up the call stack a chance to catch System.Exception or some other exception that's a base type for more specific exceptions.”
[建议译文]：把捕获System.Exception或别的身为那些更具体的异常的基类型的异常的机会让给调用堆栈中更高层的代码吧。
说明：基本接受，但感觉有些生硬
修改为：
我们应该为调用堆栈中居于较高层次的代码提供机会，使它们能够捕获System.Exception异常，或者其他一些用作较具体的异常的基础类型的异常。
----- 《CLR via C#》中文版民间勘误（十） -----
35．[位置]：374页2行。
[类型]：翻译错误。
[译文原文]：“需要特别指出的是：TryXxx方法的Boolean类型的值返回false时表示仅有一个类型转换失败。但是方法仍抛出其他类型失败的异常。例如，对于Int32的TryParse方法，如果它的参数无效，它就抛出一个ArgumentException异常，”
[英文原文]：“One thing I want to make absolutely clear: A TryXxx method's Boolean return value returns false to indicate one and only one type of failure. The method should still throw exceptions for any other type of failure. For example, Int32's TryParse throws an ArgumentException if the styles argument is not valid,”
[建议译文]：需要特别指出的是：TryXxx方法的Boolean型返回值为false代表着一种、而且仅仅是一种类型的故障。方法在遇到其它类型的故障时依然会抛出异常。例如，Int32的TryParse方法当styles参数无效时将抛出一个ArgumentException异常。
[类型]：翻译错误。
[译文原文]：“需要特别指出的是：TryXxx方法的Boolean类型的值返回false时表示仅有一个类型转换失败。但是方法仍抛出其他类型失败的异常。例如，对于Int32的TryParse方法，如果它的参数无效，它就抛出一个ArgumentException异常，”
[英文原文]：“One thing I want to make absolutely clear: A TryXxx method's Boolean return value returns false to indicate one and only one type of failure. The method should still throw exceptions for any other type of failure. For example, Int32's TryParse throws an ArgumentException if the styles argument is not valid,”
[建议译文]：需要特别指出的是：TryXxx方法的Boolean型返回值为false代表着一种、而且仅仅是一种类型的故障。方法在遇到其它类型的故障时依然会抛出异常。例如，Int32的TryParse方法当styles参数无效时将抛出一个ArgumentException异常。
说明：接受
36．[位置]：377页7行。
[类型]：翻译错误。
[译文原文]：“该功能不太友好，因为它使应用程序在字段中失败时的调试工作异常困难。”
[英文原文]：“This is unfortunate because it makes debugging applications that have failed in the field much more difficult.”
[评论]：不要一见“field”就译“字段”！
[建议译文]：这之所以令人遗憾，是因为它使实地调试发生故障的应用程序的工作变得更加困难。
[类型]：翻译错误。
[译文原文]：“该功能不太友好，因为它使应用程序在字段中失败时的调试工作异常困难。”
[英文原文]：“This is unfortunate because it makes debugging applications that have failed in the field much more difficult.”
[评论]：不要一见“field”就译“字段”！
[建议译文]：这之所以令人遗憾，是因为它使实地调试发生故障的应用程序的工作变得更加困难。
说明：接受
37．[位置]：389页倒数3行。
[类型]：翻译错误。
[译文原文]：“我是这样认为的：任何实现了Finalize方法的类型实际上在它的对象被删除之前声明它拥有这些资源。”
[英文原文]：“I think of it this way: any type that implements the Finalize method is in effect stating that all of its objects want a last meal before they are killed.”
[评论]：这个暗喻的意思很明显，不必译出其隐含的意思。就算要译出其隐含意思，那也不是译者所理解的这个意思。
[建议译文]：我是这样想象的，任何实现Finalize方法的类型实际上是在声称：所有它的对象在被处决之前都想最后再吃上一顿饭。
[类型]：翻译错误。
[译文原文]：“我是这样认为的：任何实现了Finalize方法的类型实际上在它的对象被删除之前声明它拥有这些资源。”
[英文原文]：“I think of it this way: any type that implements the Finalize method is in effect stating that all of its objects want a last meal before they are killed.”
[评论]：这个暗喻的意思很明显，不必译出其隐含的意思。就算要译出其隐含意思，那也不是译者所理解的这个意思。
[建议译文]：我是这样想象的，任何实现Finalize方法的类型实际上是在声称：所有它的对象在被处决之前都想最后再吃上一顿饭。
说明：不同意，个人认为还是意译好，如同谚语一样，直译的意思不如意译好理解。
38．[位置]：390页11行。
[类型]：印刷错误。
[译文原文]：“而对base.Finalize的调用则在block块中生成。”
[英文原文]：“and that a call to base.Finalize is emitted into a finally block.”
[评论]：“block”应该改为“finally”。另外，A在B中生成这种说法感觉有点问题，但好歹大家都明白其意思，也勉强使得。
[类型]：印刷错误。
[译文原文]：“而对base.Finalize的调用则在block块中生成。”
[英文原文]：“and that a call to base.Finalize is emitted into a finally block.”
[评论]：“block”应该改为“finally”。另外，A在B中生成这种说法感觉有点问题，但好歹大家都明白其意思，也勉强使得。
说明：接受
----- 《CLR via C#》中文版民间勘误（十一） -----
39．[位置]：391页3行。
[类型]：翻译错误。
[译文原文]：“在对象之上编译这些方法可以确保一点：”
[英文原文]：“Compiling these methods upon object construction guarantees that …”
[评论]：我怀疑译者是不是有阅读障碍。
[建议译文]：在构造对象时就编译这些方法确保了……
[类型]：翻译错误。
[译文原文]：“在对象之上编译这些方法可以确保一点：”
[英文原文]：“Compiling these methods upon object construction guarantees that …”
[评论]：我怀疑译者是不是有阅读障碍。
[建议译文]：在构造对象时就编译这些方法确保了……
说明：接受
40．[位置]：391页倒数13行（代码的注释）。
[类型]：翻译错误。
[译文原文]：“如果ownHandle为true，那么当这个派生自SafeHandle的对象被收集时，本地资源就是关闭的。”
[英文原文]：“If ownsHandle is true, then the native resource is closed when this SafeHandle-derived object is collected.”
[建议译文]：“如果ownHandle为true，那么当这个派生自SafeHandle的对象被收集时，本地资源将被关闭。”
[类型]：翻译错误。
[译文原文]：“如果ownHandle为true，那么当这个派生自SafeHandle的对象被收集时，本地资源就是关闭的。”
[英文原文]：“If ownsHandle is true, then the native resource is closed when this SafeHandle-derived object is collected.”
[建议译文]：“如果ownHandle为true，那么当这个派生自SafeHandle的对象被收集时，本地资源将被关闭。”
说明：不同意，没有将来时的含义。
41．[位置]：392页6行。
[类型]：翻译错误。
[译文原文]：“不采用ReleaseHandlerFailed的托管调试助手（MDA）”
[英文原文]：“Fire the ReleaseHandleFailed Managed Debugging Assistant (MDA)”
[评论]：看起来译者似乎把“fire”理解成“解雇”了。
[建议译文]：激活ReleaseHandleFailed托管调试助手（MDA）。
[类型]：翻译错误。
[译文原文]：“不采用ReleaseHandlerFailed的托管调试助手（MDA）”
[英文原文]：“Fire the ReleaseHandleFailed Managed Debugging Assistant (MDA)”
[评论]：看起来译者似乎把“fire”理解成“解雇”了。
[建议译文]：激活ReleaseHandleFailed托管调试助手（MDA）。
说明：接受
42．[位置]：394页倒数19行。
[类型]：翻译错误。
[译文原文]：“从而自动地构建一个SafeWaitHandle类的实例，并传递到CreateEvent函数返回的句柄值中。”
[英文原文]：“causing the CLR to automatically construct an instance of the SafeWaitHandle class, passing in the handle value returned from CreateEvent”
[建议译文]：“从而自动构建一个SafeWaitHandle类的实例，在此过程中将从CreateEvent函数返回的句柄值传递给它。”
[类型]：翻译错误。
[译文原文]：“从而自动地构建一个SafeWaitHandle类的实例，并传递到CreateEvent函数返回的句柄值中。”
[英文原文]：“causing the CLR to automatically construct an instance of the SafeWaitHandle class, passing in the handle value returned from CreateEvent”
[建议译文]：“从而自动构建一个SafeWaitHandle类的实例，在此过程中将从CreateEvent函数返回的句柄值传递给它。”
说明：接受，但与原文不太符
修改为：
将导致CLR自动地构建一个SafeWaitHandle类的实例，并将从CreateEvent函数返回的句柄值传递给它。
----- 《CLR via C#》中文版民间勘误（十二） -----
43．[位置]：395页2行。
[类型]：翻译错误。
[译文原文]：“如果编写或者调用代码操作IntPtr类型的句柄，就可以不用SafeHandle对象来访问句柄……”
[英文原文]：“If you are writing or calling code to manipulate a handle as an IntPtr, you can access it out of a SafeHandle object …”
[建议译文]：如果你编写的代码或调用的代码需要以IntPtr的形式来操作句柄，你可以从一个SafeHandle类型的对象中获取它……
[类型]：翻译错误。
[译文原文]：“如果编写或者调用代码操作IntPtr类型的句柄，就可以不用SafeHandle对象来访问句柄……”
[英文原文]：“If you are writing or calling code to manipulate a handle as an IntPtr, you can access it out of a SafeHandle object …”
[建议译文]：如果你编写的代码或调用的代码需要以IntPtr的形式来操作句柄，你可以从一个SafeHandle类型的对象中获取它……
说明：接受
修改为：
如果编写的代码或调用的代码需要以IntPtr的形式来操作句柄，则可以从一个SafeHandle对象中获取它……
44．[位置]：397页13行。
[类型]：翻译错误。
[译文原文]：“但是，在访问值类型实例或者引用类型对象时不定义Finalize方法将相当好。”
[英文原文]：“However, it is perfectly OK to access value type instances or reference type objects that do not define a Finalize method.”
[评论]：难以理解何以发生这样的错误。
[建议译文]：但是，访问值类型的实例或未定义Finalize方法的引用类型的对象则是完全可以的。
[类型]：翻译错误。
[译文原文]：“但是，在访问值类型实例或者引用类型对象时不定义Finalize方法将相当好。”
[英文原文]：“However, it is perfectly OK to access value type instances or reference type objects that do not define a Finalize method.”
[评论]：难以理解何以发生这样的错误。
[建议译文]：但是，访问值类型的实例或未定义Finalize方法的引用类型的对象则是完全可以的。
说明：接受，that是不是修饰前面的value type instances和 reference type objects两部分
修改为：
但是，访问未定义Finalize方法的值类型实例或引用类型对象时则是完全可以的。
45．[位置]：397页倒数20行。
[类型]：翻译错误。
[译文原文]：“Finalize方法在垃圾收集结束时被调用，有5种事件会导致一个对象的Finalize方法被调用：”
[英文原文]：“Finalize methods are called at the completion of a garbage collection, which is started by one of the following five events:”
[建议译文]：下列五种事件会启动垃圾收集，收集结束时会调用Finalize方法：
[类型]：翻译错误。
[译文原文]：“Finalize方法在垃圾收集结束时被调用，有5种事件会导致一个对象的Finalize方法被调用：”
[英文原文]：“Finalize methods are called at the completion of a garbage collection, which is started by one of the following five events:”
[建议译文]：下列五种事件会启动垃圾收集，收集结束时会调用Finalize方法：
说明：接受
修改为：
Finalize方法在垃圾收集结束时被调用，下列5种事件会导致垃圾收集的启动：
46．[位置]：399页倒数13行。
[类型]：翻译错误。
[译文原文]：“在终结可达队列中出现的指针标识该对象的Finalize方法即将被调用。”
[英文原文]：“Each pointer in the freachable queue identifies an object that is ready to have its Finalize method called.”
[建议译文]：终结可达队列中的每一个指针标识着一个其Finalize方法即将被调用的对象。
[类型]：翻译错误。
[译文原文]：“在终结可达队列中出现的指针标识该对象的Finalize方法即将被调用。”
[英文原文]：“Each pointer in the freachable queue identifies an object that is ready to have its Finalize method called.”
[建议译文]：终结可达队列中的每一个指针标识着一个其Finalize方法即将被调用的对象。
说明：接受
修改为：
终结可达队列中的每一个指针都标识着一个其Finalize方法即将被调用的对象。
----- 《CLR via C#》中文版民间勘误（十三） -----
47．[位置]：399页倒数3行。
[类型]：翻译错误。
[译文原文]：“我们不应该执行对正在执行代码的线程做任何假设的Finalize方法中的任何代码。”
[英文原文]：“you shouldn't execute any code in a Finalize method that makes any assumptions about the thread that's executing the code”
[建议译文]：你不应该在Finalize方法中执行任何对其执行线程有所假设的代码。
[类型]：翻译错误。
[译文原文]：“我们不应该执行对正在执行代码的线程做任何假设的Finalize方法中的任何代码。”
[英文原文]：“you shouldn't execute any code in a Finalize method that makes any assumptions about the thread that's executing the code”
[建议译文]：你不应该在Finalize方法中执行任何对其执行线程有所假设的代码。
说明：接受
修改为：
我们不应该在Finalize方法中执行任何对执行代码的线程有任何假设的代码。
48．[位置]：408页倒数16行。
[类型]：翻译不当。
[译文原文]：“Mutex类确实实现了IDisposable接口，但是在释放本地资源时调用了Dispose方法，并且Mutex类不对锁本身做任何处理。”
[英文原文]：“The Mutex class does implement the IDisposable interface, but calling Dispose on it releases the native resource; it has nothing to do with the lock itself.”
[建议译文]：Mutex类的确实现了Idisposable接口，但是对其Dispose方法的调用只是释放本地资源，这与锁本身没什么关系。
[类型]：翻译不当。
[译文原文]：“Mutex类确实实现了IDisposable接口，但是在释放本地资源时调用了Dispose方法，并且Mutex类不对锁本身做任何处理。”
[英文原文]：“The Mutex class does implement the IDisposable interface, but calling Dispose on it releases the native resource; it has nothing to do with the lock itself.”
[建议译文]：Mutex类的确实现了Idisposable接口，但是对其Dispose方法的调用只是释放本地资源，这与锁本身没什么关系。
说明：接受
49．[位置]：410页倒数11行。
[类型]：翻译错误。
[译文原文]：“.NET Framework 2.0提供了一个称为托管调试助手（MDA）的辅助调试应用程序。启用MDA后，.NET Framework查找公共的编程错误，并且启动一个相应的MDA。在调试器中，MDA就像抛出一个异常。检测到StreamWriter对象在被垃圾收集之前没有显式地进行关闭时，就会出现一个可以利用的MDA。为了在Visual Studio中启用MDA……”
[英文原文]：“Version 2.0 of the .NET Framework offers a feature called Managed Debugging Assistants (MDA).When an MDA is enabled, the .NET Framework looks for certain common programmer errors and fires a corresponding MDA. In the debugger, it looks like an exception has been thrown. There is an MDA available to detect when a StreamWriter object is garbage collected without having prior been explicitly closed. To enable this MDA in Visual Studio,”
[评论]：大面积的错误。
[建议译文]：.NET框架的2.0版本提供了一个名为托管调试助手（MDA）的特性。启用一个MDA后，.NET框架就会查找特定种类的常见的编程错误，并为其激活相应的MDA。这在调试器中看起来仿佛是有一个异常被抛出一样。有一个MDA就是用于探测StreamWriter对象未曾被显式关闭过就被作为垃圾收集这种情况的。为了在Visual Studio中启用这个MDA……
[类型]：翻译错误。
[译文原文]：“.NET Framework 2.0提供了一个称为托管调试助手（MDA）的辅助调试应用程序。启用MDA后，.NET Framework查找公共的编程错误，并且启动一个相应的MDA。在调试器中，MDA就像抛出一个异常。检测到StreamWriter对象在被垃圾收集之前没有显式地进行关闭时，就会出现一个可以利用的MDA。为了在Visual Studio中启用MDA……”
[英文原文]：“Version 2.0 of the .NET Framework offers a feature called Managed Debugging Assistants (MDA).When an MDA is enabled, the .NET Framework looks for certain common programmer errors and fires a corresponding MDA. In the debugger, it looks like an exception has been thrown. There is an MDA available to detect when a StreamWriter object is garbage collected without having prior been explicitly closed. To enable this MDA in Visual Studio,”
[评论]：大面积的错误。
[建议译文]：.NET框架的2.0版本提供了一个名为托管调试助手（MDA）的特性。启用一个MDA后，.NET框架就会查找特定种类的常见的编程错误，并为其激活相应的MDA。这在调试器中看起来仿佛是有一个异常被抛出一样。有一个MDA就是用于探测StreamWriter对象未曾被显式关闭过就被作为垃圾收集这种情况的。为了在Visual Studio中启用这个MDA……
说明：接受
50．[位置]：412页16行。
[类型]：翻译错误。
[译文原文]：“我们可以以GCHandle实例作为参数调用Free方法（该方法通过将IntPtr字段设为0也会使实例无效）。”
[英文原文]：“you take the GCHandle instance and call the Free method (which also invalidates the instance by setting the IntPtr field to zero).”
[建议译文]：你使用该GCHandler实例调用Free方法（它也会通过将IntPtr字段设置为0来使该实例无效）。
[类型]：翻译错误。
[译文原文]：“我们可以以GCHandle实例作为参数调用Free方法（该方法通过将IntPtr字段设为0也会使实例无效）。”
[英文原文]：“you take the GCHandle instance and call the Free method (which also invalidates the instance by setting the IntPtr field to zero).”
[建议译文]：你使用该GCHandler实例调用Free方法（它也会通过将IntPtr字段设置为0来使该实例无效）。
说明：接受
修改为：
我们可以使用GCHandle实例调用Free方法（它通过将IntPtr字段设为0也会使实例无效）
----- 《CLR via C#》中文版民间勘误（十四） -----
51．[位置]：414页4行。
[类型]：翻译错误。
[译文原文]：“MailManager对象将返回的GCHandler实例保存在一个垃圾收集中（而不是保存委托对象的引用）。”
[英文原文]：“The MailManager object will save the returned GCHandle instance in a collection instead of saving the reference to the delegate object.”
[建议译文]：MailManager对象在一个集合中保存所返回的GCHandle实例，而不是保存对该委托对象的引用。
[类型]：翻译错误。
[译文原文]：“MailManager对象将返回的GCHandler实例保存在一个垃圾收集中（而不是保存委托对象的引用）。”
[英文原文]：“The MailManager object will save the returned GCHandle instance in a collection instead of saving the reference to the delegate object.”
[建议译文]：MailManager对象在一个集合中保存所返回的GCHandle实例，而不是保存对该委托对象的引用。
说明：接受
52．[位置]：414页倒数13行。
[类型]： 翻译错误。
[译文原文]：“WeakReference类底部的对象也称为类。”
[英文原文]：“The downside of the WeakReference class is that it is a class.”
[评论]：太荒唐了！我们的译者太有才了！
[建议译文]：WeakReference类的缺点在于它是一个类。
[类型]： 翻译错误。
[译文原文]：“WeakReference类底部的对象也称为类。”
[英文原文]：“The downside of the WeakReference class is that it is a class.”
[评论]：太荒唐了！我们的译者太有才了！
[建议译文]：WeakReference类的缺点在于它是一个类。
说明：接受
53．[位置]：416页倒数6行。
[类型]：翻译错误。
[译文原文]：“当内存充满或者接近充满时，垃圾收集不会发生。相反，无论何时，只要第0代充满，垃圾收集操作就会发生，”
[英文原文]：“Garbage collections do not occur when memory is full or close to full. Instead, garbage collections occur whenever generation 0 is full,”
[建议译文]：垃圾收集不是发生在内存占满或即将占满时，而是每当第0代占满时就发生。
[类型]：翻译错误。
[译文原文]：“当内存充满或者接近充满时，垃圾收集不会发生。相反，无论何时，只要第0代充满，垃圾收集操作就会发生，”
[英文原文]：“Garbage collections do not occur when memory is full or close to full. Instead, garbage collections occur whenever generation 0 is full,”
[建议译文]：垃圾收集不是发生在内存占满或即将占满时，而是每当第0代占满时就发生。
说明：接受
54．[位置]：417页倒数19行。
[类型]：翻译错误。
[译文原文]：“但是，如以下代码所示，如果Finalize方法执行的代码中放了一个指向静态字段中的对象的指针，情况又会怎么样呢？”
[英文原文]：“But what if an object's Finalize method executed code that placed a pointer to the object in a static field, as demonstrated in the following code?”
[建议译文]：但是，如果对象的Finalize方法执行的代码，如下所示，把一个指向该对象的指针存入一个静态字段中，那又该如何呢？
[类型]：翻译错误。
[译文原文]：“但是，如以下代码所示，如果Finalize方法执行的代码中放了一个指向静态字段中的对象的指针，情况又会怎么样呢？”
[英文原文]：“But what if an object's Finalize method executed code that placed a pointer to the object in a static field, as demonstrated in the following code?”
[建议译文]：但是，如果对象的Finalize方法执行的代码，如下所示，把一个指向该对象的指针存入一个静态字段中，那又该如何呢？
说明：接受
----- 《CLR via C#》中文版民间勘误（十五） -----
55．[位置]：418页倒数17行。
[类型]：翻译错误。
[译文原文]：“更常见的做法是在Finalize方法内部设置一个根来引用对象从而使对象复苏。”
[英文原文]：“It's far more common to conditionally set a root to reference the object inside the Finalize method.”
[建议译文]：更常见的做法是在Finalize方法中条件性地让一个根引用对象。
[类型]：翻译错误。
[译文原文]：“更常见的做法是在Finalize方法内部设置一个根来引用对象从而使对象复苏。”
[英文原文]：“It's far more common to conditionally set a root to reference the object inside the Finalize method.”
[建议译文]：更常见的做法是在Finalize方法中条件性地让一个根引用对象。
说明：接受
56．[位置]：422页11行。
[类型]：翻译不当。
[译文原文]：“在那些线程在其堆栈顶部大部分时间都空闲的应用程序中垃圾收集器的工作情况相当出色。”
[英文原文]：“The garbage collector works extremely well for applications with threads that sit idle at the top of their stack most of the time.”
[建议译文]：有些应用程序，其线程大部分时间都无所事事，它们的堆栈因此大部分时间都处在顶部位置（栈中空空如已）。对于这类程序，垃圾收集器工作得尤其出色。
[类型]：翻译不当。
[译文原文]：“在那些线程在其堆栈顶部大部分时间都空闲的应用程序中垃圾收集器的工作情况相当出色。”
[英文原文]：“The garbage collector works extremely well for applications with threads that sit idle at the top of their stack most of the time.”
[建议译文]：有些应用程序，其线程大部分时间都无所事事，它们的堆栈因此大部分时间都处在顶部位置（栈中空空如已）。对于这类程序，垃圾收集器工作得尤其出色。
说明：接受
57．[位置]：422页倒数15行。
[类型]：翻译不当。
[译文原文]：“实际上，大多数应用程序的根生存在参数或者局部变量的线程的堆栈中。”
[英文原文]：“In fact, most of an application's roots live on the thread's stack in arguments or local variables.”
[建议译文]：实际上，应用程序的大多数根都以参数或局部变量的形式存在于线程的堆栈上。
[类型]：翻译不当。
[译文原文]：“实际上，大多数应用程序的根生存在参数或者局部变量的线程的堆栈中。”
[英文原文]：“In fact, most of an application's roots live on the thread's stack in arguments or local variables.”
[建议译文]：实际上，应用程序的大多数根都以参数或局部变量的形式存在于线程的堆栈上。
说明：接受
58．[位置]：440页倒数6行。
[类型]：翻译错误。
[译文原文]：“然而，共享这些资源的收益没有与投入成正比。”
[英文原文]：“Unfortunately, the benefit gained by sharing these resources does come with a price”
[建议译文]：可惜共享这些资源所带来的好处是有代价的。
[类型]：翻译错误。
[译文原文]：“然而，共享这些资源的收益没有与投入成正比。”
[英文原文]：“Unfortunately, the benefit gained by sharing these resources does come with a price”
[建议译文]：可惜共享这些资源所带来的好处是有代价的。
说明：接受
----- 《CLR via C#》中文版民间勘误（十六） -----
59．[位置]：446页倒数8行。
[类型]：翻译错误。
[译文原文]：“在任意时刻，一个应用程序域只能执行一个线程。”
[英文原文]：“at any given time, a thread is considered to be in just one AppDomain.”
[建议译文]：在任一给定时刻，一个线程只能运行在一个应用程序域之中。
[类型]：翻译错误。
[译文原文]：“在任意时刻，一个应用程序域只能执行一个线程。”
[英文原文]：“at any given time, a thread is considered to be in just one AppDomain.”
[建议译文]：在任一给定时刻，一个线程只能运行在一个应用程序域之中。
说明：接受
60．[位置]：447页倒数4行。
[类型]：翻译错误。
[译文原文]：“因为CLR实际上要结束调用方法来执行字段的访问。”
[英文原文]：“because the CLR really ends up calling methods to perform the field access”
[建议译文]：因为CLR实际上最终要通过调用方法来执行字段访问。
[类型]：翻译错误。
[译文原文]：“因为CLR实际上要结束调用方法来执行字段的访问。”
[英文原文]：“because the CLR really ends up calling methods to perform the field access”
[建议译文]：因为CLR实际上最终要通过调用方法来执行字段访问。
说明：接受
61．[位置]：451页5行。
[类型]：翻译错误。
[译文原文]：“无论何时，只要代码调用AppDomain.Unload方法，被卸载应用程序域中就没有任何线程，因此，CLR不必抛出ThreadAbortException异常。”
[英文原文]：“Whenever my code calls AppDomain.Unload, there are no threads in the unloading AppDomain, and therefore, the CLR doesn't have to throw any ThreadAbortException exceptions.”
[建议译文]：我的代码中，在调用AppDomain.Unload的时候，所卸载的AppDomain中都没有线程在运行，所以CLR也就用不着抛出ThreadAbortException异常。
[类型]：翻译错误。
[译文原文]：“无论何时，只要代码调用AppDomain.Unload方法，被卸载应用程序域中就没有任何线程，因此，CLR不必抛出ThreadAbortException异常。”
[英文原文]：“Whenever my code calls AppDomain.Unload, there are no threads in the unloading AppDomain, and therefore, the CLR doesn't have to throw any ThreadAbortException exceptions.”
[建议译文]：我的代码中，在调用AppDomain.Unload的时候，所卸载的AppDomain中都没有线程在运行，所以CLR也就用不着抛出ThreadAbortException异常。
说明：不同意，这里强调的是Whenever，而不是my
62．[位置]：466页1行。
[类型]：翻译不当。
[译文原文]：“我们可以为GetType方法传递一个合乎程序集类型条件（assembly-qualified type）的字符串，例如……。”
[英文原文]：“You can pass an assembly-qualified type string, such as "System.Int32, mscorlib, Version= 2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089", to GetType.”
[评论]：“合乎程序集类型条件的字符串”这种译法不妥，让人看得莫明其妙。“qualified”在这种场合的含义是“restricted”或“modified”。国内技术图书通常把这种用法的“qualified”译为“限定”。比如“full-qualified name”一般译为“完全限定名”。
[建议译文]：可以传给GetType方法一个程序集限定的类型字符串，比如……
[类型]：翻译不当。
[译文原文]：“我们可以为GetType方法传递一个合乎程序集类型条件（assembly-qualified type）的字符串，例如……。”
[英文原文]：“You can pass an assembly-qualified type string, such as "System.Int32, mscorlib, Version= 2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089", to GetType.”
[评论]：“合乎程序集类型条件的字符串”这种译法不妥，让人看得莫明其妙。“qualified”在这种场合的含义是“restricted”或“modified”。国内技术图书通常把这种用法的“qualified”译为“限定”。比如“full-qualified name”一般译为“完全限定名”。
[建议译文]：可以传给GetType方法一个程序集限定的类型字符串，比如……
说明：接受
----- 《CLR via C#》中文版民间勘误（十七） -----
63．[位置]：469页13行。
[类型]：翻译错误。
[译文原文]：“ObjectHandle类型允许我们在一个应用程序域中创建一个对象，然后将其传递到其他的应用程序域中，但不能强制对象进行具体化（materialize）。准备具体化该对象时，可以调用ObjectHandle的Unwrap方法。该方法加载在调用Unwrap方法的应用程序域中定义的被具体化的类型的程序集。”
[英文原文]：“An ObjectHandle is a type that allows an object created in one AppDomain to be passed around to other AppDomains without forcing the object to materialize. When you're ready to materialize the object, you call ObjectHandle's Unwrap method. This method loads the assembly that defines the type being materialized in the AppDomain where Unwrap is called.”
[建议译文]：ObjectHandle类型允许将一个应用程序域中创建的对象传递到其它应用程序域，而且在此过程中不必将该对象具体化。准备具体化该对象时，调用ObjectHandle的Unwrap方法即可。该方法在调用Unwrap的应用程序域中加载定义了所要具体化的类型的程序集。
[类型]：翻译错误。
[译文原文]：“ObjectHandle类型允许我们在一个应用程序域中创建一个对象，然后将其传递到其他的应用程序域中，但不能强制对象进行具体化（materialize）。准备具体化该对象时，可以调用ObjectHandle的Unwrap方法。该方法加载在调用Unwrap方法的应用程序域中定义的被具体化的类型的程序集。”
[英文原文]：“An ObjectHandle is a type that allows an object created in one AppDomain to be passed around to other AppDomains without forcing the object to materialize. When you're ready to materialize the object, you call ObjectHandle's Unwrap method. This method loads the assembly that defines the type being materialized in the AppDomain where Unwrap is called.”
[建议译文]：ObjectHandle类型允许将一个应用程序域中创建的对象传递到其它应用程序域，而且在此过程中不必将该对象具体化。准备具体化该对象时，调用ObjectHandle的Unwrap方法即可。该方法在调用Unwrap的应用程序域中加载定义了所要具体化的类型的程序集。
说明：接受
64．[位置]：471页倒数20行。
[类型]：翻译不当。
[译文原文]：“插件开发人员可以按他们的愿望设计一个新版本的程序集，而宿主应用程序无论怎样使用插件类型，也都不会出现任何问题。”
[英文原文]：“The add-in developers are able to put out a new version of their assembly as often as they'd like, and the host application will be able to consume the add-in types without any problem whatsoever.”
[建议译文]：插件开发者可以按自己的频度发布其程序集的新版本，宿主应用程序不会因此而在使用这些插件方面出现任何问题。
[类型]：翻译不当。
[译文原文]：“插件开发人员可以按他们的愿望设计一个新版本的程序集，而宿主应用程序无论怎样使用插件类型，也都不会出现任何问题。”
[英文原文]：“The add-in developers are able to put out a new version of their assembly as often as they'd like, and the host application will be able to consume the add-in types without any problem whatsoever.”
[建议译文]：插件开发者可以按自己的频度发布其程序集的新版本，宿主应用程序不会因此而在使用这些插件方面出现任何问题。
说明：基本同意
修改为：
插件开发人员可以按他们的意愿发布新版本的程序集，而宿主应用程序在使用这些插件时不会因此而出现问题。
65．[位置]：471页倒数11行。
[类型]：翻译错误。
[译文原文]：“需要花费一些时间，通过将跨程序集边界通信所用的类型隔离，在程序集中设计一个结构清晰的类型。”
[英文原文]：“Take your time to architect this cleanly by isolating the types that you use for communication across assembly boundaries into their own assembly.”
[建议译文]：花点时间，通过将用于跨程序集边界通信的类型隔离到它们自己的程序集之中，以获得一个清晰的架构。
[类型]：翻译错误。
[译文原文]：“需要花费一些时间，通过将跨程序集边界通信所用的类型隔离，在程序集中设计一个结构清晰的类型。”
[英文原文]：“Take your time to architect this cleanly by isolating the types that you use for communication across assembly boundaries into their own assembly.”
[建议译文]：花点时间，通过将用于跨程序集边界通信的类型隔离到它们自己的程序集之中，以获得一个清晰的架构。
说明：接受
66．[位置]：478页6行（不计表格）。
[类型]：翻译错误。
[译文原文]：“只有设置BindingFlags的IgnoreCase，这些方法才有用武之地。”
[英文原文]：“This is when BindingFlags's IgnoreCase flag comes in handy.”
[建议译文]：BindingFlags的IgnoreCase标志在此可以派上用场。
[类型]：翻译错误。
[译文原文]：“只有设置BindingFlags的IgnoreCase，这些方法才有用武之地。”
[英文原文]：“This is when BindingFlags's IgnoreCase flag comes in handy.”
[建议译文]：BindingFlags的IgnoreCase标志在此可以派上用场。
说明：接受
----- 《CLR via C#》中文版民间勘误（十八） -----
67．[位置]：497页4行。
[类型]：翻译错误。
[译文原文]：“为了让线程继续运行，线程可以在线程池的队列中加入一个工作项，让线程池中的线程来执行打开文件的代码。当然，这必须在拥有合适许可权限的程序集中进行。这种‘工作区’智取安全权限的现象可以允许怀恶意的代码对受限资源进行严重破坏。为了阻止这种获得安全权限的方式，……”
[英文原文]：“To work around this, the thread could queue a work item to the thread pool and have the thread pool thread execute code to open the file. Of course, this would have to be in an assembly that has the right permission. This "workaround" circumvents security and allows malicious code to wreak havoc with restricted resources. To prevent this security exploit, …”
[建议译文]：为了绕过这种限制，该线程可能会把一个工作项加入线程池的队列，让线程池中的线程执行打开文件的代码。当然，这得在拥有合适权限的程序集中进行。这种“绕行”规避了安全机制，让恶意代码得以对受限资源造成重大破坏。为了阻止这种瞒天过海的花招，……
[类型]：翻译错误。
[译文原文]：“为了让线程继续运行，线程可以在线程池的队列中加入一个工作项，让线程池中的线程来执行打开文件的代码。当然，这必须在拥有合适许可权限的程序集中进行。这种‘工作区’智取安全权限的现象可以允许怀恶意的代码对受限资源进行严重破坏。为了阻止这种获得安全权限的方式，……”
[英文原文]：“To work around this, the thread could queue a work item to the thread pool and have the thread pool thread execute code to open the file. Of course, this would have to be in an assembly that has the right permission. This "workaround" circumvents security and allows malicious code to wreak havoc with restricted resources. To prevent this security exploit, …”
[建议译文]：为了绕过这种限制，该线程可能会把一个工作项加入线程池的队列，让线程池中的线程执行打开文件的代码。当然，这得在拥有合适权限的程序集中进行。这种“绕行”规避了安全机制，让恶意代码得以对受限资源造成重大破坏。为了阻止这种瞒天过海的花招，……
说明：接受
68．[位置]：513页倒数16行。
[类型]：翻译错误。
[译文原文]：“调用者在执行异步I/O操作时就可以使用这个IasyncResult对象了。”
[英文原文]：“The caller can now use this object as it would when performing an asynchronous I/O operation.”
[类型]：翻译错误。
[译文原文]：“调用者在执行异步I/O操作时就可以使用这个IasyncResult对象了。”
[英文原文]：“The caller can now use this object as it would when performing an asynchronous I/O operation.”
[建议译文]：调用者现在就可以按类似于执行异步I/O操作时所用的套路来使用这个对象了。
说明：接受
69．[位置]：524页10行。
[类型]：翻译不当。
[译文原文]：“另外，我们还可以将volatile关键字应用于引用类型以及任何只要枚举类型的基础类型是Byte，Sbyte，Int16，UInt16，Int32，UInt32，Single和Boolean的枚举字段。”
[英文原文]：“You can also apply the volatile keyword to reference types and any enum field as long as the enumerated type has an underlying type of Byte, SByte, Int16, UInt16, Int32, UInt32, Single, or Boolean.”
[建议译文]：volatile关键字还可以用于引用类型的字段，以及其基础类型为Byte、 Sbyte、 Int16、 UInt16、 Int32、 UInt32、 Single或Boolean的枚举类型的字段。
[类型]：翻译不当。
[译文原文]：“另外，我们还可以将volatile关键字应用于引用类型以及任何只要枚举类型的基础类型是Byte，Sbyte，Int16，UInt16，Int32，UInt32，Single和Boolean的枚举字段。”
[英文原文]：“You can also apply the volatile keyword to reference types and any enum field as long as the enumerated type has an underlying type of Byte, SByte, Int16, UInt16, Int32, UInt32, Single, or Boolean.”
[建议译文]：volatile关键字还可以用于引用类型的字段，以及其基础类型为Byte、 Sbyte、 Int16、 UInt16、 Int32、 UInt32、 Single或Boolean的枚举类型的字段。
说明：另外，我们还可以将volatile关键字应用于引用类型的字段，以及任何只要基础类型是Byte、Sbyte、Int16、UInt16、Int32、UInt32、Single或Boolean的枚举类型的字段。
70．[位置]：526页中间部分的代码。
[类型]：翻译错误加印刷错误。
[评论]：1. 所有注释中的“自动执行”，其英文为“Atomically performs”，应该译为“原子性地执行”。2. Decrement方法的注释应该是“//原子性地执行（location--）”。3. Add方法的注释第一行应该是“//原子性地执行（location+=value）”；第二行原译“//说明：值可以是一个可进行减法算的负值”不正确，应该译为“//说明：value可以是负值，以实现减法运算”。
[类型]：翻译错误加印刷错误。
[评论]：1. 所有注释中的“自动执行”，其英文为“Atomically performs”，应该译为“原子性地执行”。2. Decrement方法的注释应该是“//原子性地执行（location--）”。3. Add方法的注释第一行应该是“//原子性地执行（location+=value）”；第二行原译“//说明：值可以是一个可进行减法算的负值”不正确，应该译为“//说明：value可以是负值，以实现减法运算”。
说明：基本同意，将3中说明译为：“/说明：value可以是负值，从而允许进行减法运算”
----- 《CLR via C#》中文版民间勘误（十九） -----
71．[位置]：528页15行。
[类型]：翻译不当。
[译文原文]：“所有的开发人员不得不在每个需要线程同步的方法中编写必须的代码以进入或者离开该字段。”
[英文原文]：“All the developer has to do is write code to enter and leave the field as necessary in each method that requires thread synchronization.”
[建议译文]：开发人员要做的只是在每一个需要线程同步的方法中按要求编写代码以进入和离开该字段。
[类型]：翻译不当。
[译文原文]：“所有的开发人员不得不在每个需要线程同步的方法中编写必须的代码以进入或者离开该字段。”
[英文原文]：“All the developer has to do is write code to enter and leave the field as necessary in each method that requires thread synchronization.”
[建议译文]：开发人员要做的只是在每一个需要线程同步的方法中按要求编写代码以进入和离开该字段。
说明：不同意
修改为：
“开发人员不得不要做的全部事情，就是在每个需要线程同步的方法中编写必要的代码以进入或者离开该字段。”
72．[位置]：535页5行。
[类型]：翻译错误。
[译文原文]：“Monitor类应该被设计为这样，即我们可以利用它构建一个Monitor类型的静态实例从而创建一个线程同步锁。而且静态方法应该是可以操作锁对象本身的实例方法，因此，我们就不必对Monitor的任何方法传递System.Object参数。这样会解决所有的问题，并为所有的开发人员简化编程模型。顺便说一下，前面的代码在同步静态方法上表现一般，如果要同步静态方法，只需将所有成员的修饰符改为static，之后代码就可以正常工作了。”
[英文原文]：“It should have been designed so that you construct an instance of the Monitor type to create a thread synchronization lock. Then, the static methods would have been instance methods that operate on the lock object itself, and therefore, you wouldn't need to pass a System.Object argument to any of Monitor's methods. This would have solved all of the problems and would have simplified the programming model for all developers. By the way, the code above is trivially modified to synchronize static methods; just change all of the members to static, and everything just works.”
[评论]：一连串似是而非的句子。不知道译者自己是否明白他要表达的意思（比如什么“静态实例”、“表现一般”之类）？反正我是看不懂。
[建议译文]：它的设计应该允许你构建一个Monitor类型的实例，以创建一个线程同步锁。这样的话，那些静态方法就应该改为对锁对象自身进行操作的实例方法，于是，你也不用再给Monitor类的任何方法传递一个System.Object参数了。这将会解决所有的问题，并为所有开发者简化编程模型。顺便提一句
[类型]：翻译错误。
[译文原文]：“Monitor类应该被设计为这样，即我们可以利用它构建一个Monitor类型的静态实例从而创建一个线程同步锁。而且静态方法应该是可以操作锁对象本身的实例方法，因此，我们就不必对Monitor的任何方法传递System.Object参数。这样会解决所有的问题，并为所有的开发人员简化编程模型。顺便说一下，前面的代码在同步静态方法上表现一般，如果要同步静态方法，只需将所有成员的修饰符改为static，之后代码就可以正常工作了。”
[英文原文]：“It should have been designed so that you construct an instance of the Monitor type to create a thread synchronization lock. Then, the static methods would have been instance methods that operate on the lock object itself, and therefore, you wouldn't need to pass a System.Object argument to any of Monitor's methods. This would have solved all of the problems and would have simplified the programming model for all developers. By the way, the code above is trivially modified to synchronize static methods; just change all of the members to static, and everything just works.”
[评论]：一连串似是而非的句子。不知道译者自己是否明白他要表达的意思（比如什么“静态实例”、“表现一般”之类）？反正我是看不懂。
[建议译文]：它的设计应该允许你构建一个Monitor类型的实例，以创建一个线程同步锁。这样的话，那些静态方法就应该改为对锁对象自身进行操作的实例方法，于是，你也不用再给Monitor类的任何方法传递一个System.Object参数了。这将会解决所有的问题，并为所有开发者简化编程模型。顺便提一句
分享到：
发表评论
相关推荐
内容概要：本文详细介绍了8轴插补运动控制系统的实现，重点探讨了双DMA技术的应用，实现了高频率脉冲输出（最高可达500kHz）。文中首先解释了双DMA的工作原理及其相对于传统脉冲输出方式的优势，即减少CPU负载并提高数据传输速率。接着阐述了8轴插补算法的设计思想，包括基于时间分割的方法来确定各轴在特定时间段内的脉冲数。此外，还讨论了加减速控制策略，尤其是S型加减速算法的应用，以确保运动的平顺性。最后，文章展示了具体的代码实现细节，涵盖DMA配置、插补算法、加减速控制等方面。 适合人群：从事运动控制系统开发的技术人员，尤其是对嵌入式系统有一定了解的研发人员。 使用场景及目标：适用于需要高精度、高频脉冲输出的工业应用场景，如工业机器人、3D打印、激光切割等。目标是帮助开发者理解和掌握8轴插补运动控制的关键技术和实现方法，从而应用于实际项目中。 其他说明：文中提供的代码示例主要基于STM32系列单片机，但相关概念和技术可以迁移至其他平台。同时，强调了硬件细节处理的重要性，如RC滤波电路的应用，以应对实际工程中的常见问题。
2303040222橡胶232熊文栋（苯乙烯悬浮聚合）副本.pdf
内容概要：本文详细介绍了音乐喷泉的设计与制作过程，涵盖了从原理图绘制到具体代码实现的各个方面。首先介绍了Altium Designer这款强大的电子设计软件，接着展示了如何利用现有文件进行设计，包括水泵控制、灯光效果和音乐解析三大核心模块的具体实现方法。文中提供了多个代码片段，如单片机控制喷头升降、PWM调速控制水泵以及灯光效果同步音乐节奏等。同时，强调了在实际制作过程中需要注意的问题，如焊接温度、布线规划、元件选择等。此外，还分享了一些实用技巧和经验教训，帮助读者更好地理解和应用相关知识。 适合人群：对电子设计感兴趣的爱好者、初学者以及有一定基础的电子工程师。 使用场景及目标：适用于希望深入了解音乐喷泉工作原理和技术实现的人群，目标是掌握如何使用Altium Designer完成音乐喷泉的电路设计，并能够编写相应的控制代码。 其他说明：文章不仅提供了详细的理论讲解，还包括了许多实战经验和技巧，有助于读者在实践中少走弯路。
内容概要：本文详细介绍了汽车主动悬架系统的工作原理及其参数仿真的方法。首先解释了主动悬架的基本概念，即它可以根据车辆行驶状态和路面情况进行实时调整，提高行车安全性和舒适度。接着展示了如何利用简化的单自由度模型进行参数设置并进行仿真，具体涉及到了动力学方程、状态空间模型以及PID控制器的设计。此外还提到了更高级别的LQR控制器的应用，并强调了实际应用中需要注意的问题，如执行器响应延迟、物理限制等。文中通过实例演示了被动悬架与主动悬架在面对相同路面输入时的不同表现，突出了主动控制系统的优势。同时，针对传感器噪声处理、卡尔曼滤波器的使用、PWM信号生成等方面进行了深入探讨，揭示了主动悬架背后的复杂技术和工程挑战。 适用人群：对汽车工程特别是悬架系统感兴趣的研究人员和技术爱好者。 使用场景及目标：帮助读者理解主动悬架的工作机制，掌握基本的建模和仿真技能，为进一步开展相关领域的研究提供理论支持和技术指导。 其他说明：文中不仅提供了详细的数学推导和代码片段，还分享了许多实践经验，使读者能够全面地了解主动悬架系统的各个方面。
(3)请修改代码，解决临界区问题。解决后，无论如何运行，counter值均输出0
少儿编程scratch项目源代码文件案例素材-Mc v2.zip
内容概要：本文详细介绍了将Carsim与Simulink联合用于十四自由度车辆动力学模型的构建与验证过程。文中首先概述了整车架构的模块化分解方法，接着深入探讨了各个子系统的具体实现细节，如转向系统、轮胎模型、悬架子系统以及PI驾驶员控制器的设计与调优。针对联合仿真过程中遇到的关键问题，如采样率同步、参数调优、模型验证等进行了详细的讨论，并提供了具体的解决方案和技术技巧。通过对多种典型工况（如阶跃转向、正弦油门、双移线等）的仿真测试，验证了所建立模型的有效性和准确性。 适合人群：从事车辆动力学研究、汽车仿真领域的工程师和技术人员，尤其是那些希望深入了解Carsim与Simulink联合仿真的从业者。 使用场景及目标：适用于需要进行复杂车辆动力学仿真和模型验证的研究机构或企业。主要目标是提高仿真精度，缩短开发周期，确保模型能够准确反映实际车辆行为。此外，还可以作为教学材料帮助学生掌握先进的车辆建模技术和仿真工具。 其他说明：文中不仅分享了大量的实战经验和技巧，还附带了完整的源代码和详细的调试记录，对于想要深入理解和应用这一技术的人来说非常有价值。
内容概要：本文探讨了基于雨流计数法的源-荷-储双层协同优化配置，旨在提高能源系统的效率和经济性。文中介绍了双层优化架构，即外层优化储能系统的功率和容量，内层优化储能系统的充放电曲线并评估其寿命。通过Python代码示例展示了具体的实现过程，包括外层和内层优化的具体步骤以及雨流计数法的应用。此外，文章还讨论了常见的调试问题及解决方案，强调了内外层变量之间的相互影响。 适合人群：从事能源系统优化的研究人员和技术人员，尤其是对储能系统优化感兴趣的读者。 使用场景及目标：适用于需要进行源-荷-储系统优化的实际工程项目，如光伏电站、风力发电站等。目标是通过合理的储能配置，延长储能系统的使用寿命，降低成本，提高经济效益。 其他说明：文章提供了详细的代码示例和理论解释，帮助读者更好地理解和应用这一优化方法。同时提醒读者，在实际应用中需要注意数据的准确性以及参数的选择。
很多盗版PCI卡都在用的雕刻机控制程序
内容概要：本文详细介绍了三机并联的风光储混合系统在Matlab中的仿真方法及其关键技术。首先，针对光伏阵列模型，讨论了其核心二极管方程以及MPPT（最大功率点跟踪）算法的应用，强调了环境参数对输出特性的影响。接着，探讨了永磁同步风机的矢量控制，尤其是转速追踪和MPPT控制策略。对于混合储能系统，则深入讲解了超级电容和蓄电池的充放电策略，以及它们之间的协调机制。此外，还涉及了PQ控制的具体实现，包括双闭环结构的设计和锁相环的优化。最后，提供了仿真过程中常见的问题及解决方案，如求解器选择、参数敏感性和系统稳定性等。 适合人群：从事电力电子、新能源系统设计与仿真的工程师和技术人员，以及相关专业的研究生。 使用场景及目标：适用于希望深入了解风光储混合系统工作原理的研究人员，旨在帮助他们掌握Matlab仿真技巧，提高系统设计和优化的能力。 其他说明：文中不仅提供了详细的理论推导和代码示例，还分享了许多实践经验，有助于读者更好地理解和应用所学知识。
内容概要：本文详细介绍了基于NGSIM数据对Wiedemann99跟驰模型进行参数标定的过程。作者使用Matlab编写代码，实现了数据读取与预处理、Wiedemann99模型定义、拟合优度函数（RMSPE）计算以及改进粒子群算法（IPSO）。通过这些步骤，成功地对标定了Wiedemann99模型的关键参数，并对其进行了性能评估。文中不仅展示了具体的代码实现细节，还探讨了参数选择、算法改进等方面的经验教训。 适合人群：从事交通工程、智能交通系统研究的专业人士，尤其是那些对车辆跟驰行为建模感兴趣的科研工作者和技术开发者。 使用场景及目标：适用于需要精确模拟车辆跟驰行为的研究项目，如交通流量仿真、自动驾驶测试等。目标是提高模型的准确性和可靠性，以便更好地理解和预测真实的道路交通状况。 其他说明：文章提供了详细的代码片段和理论背景介绍，有助于读者深入理解整个标定流程。同时，作者分享了一些实用的小技巧，如参数敏感度分析、适应度函数设计等，对于相关领域的研究人员具有较高的参考价值。
内容概要：本文为中国信息通信研究院发布的《2024年大模型落地路线图研究报告》，旨在梳理大模型应用落地的共性需求和关键要素，为大模型赋能各行业提供参考。报告重点介绍了大模型应用落地的四个重要阶段——现状诊断、能力建设、应用部署、运营管理，归纳了八个关键步骤，包括能力分析、需求挖掘、方案设计、研发测试、应用开发、效能评估、运维监测和运营管理。报告详细分析了大模型在基础设施、数据资源、算法模型、应用服务、安全可信五个层面应重点关注的发展要素和亟待解决的问题。此外，报告还探讨了大模型在金融、工业、教育、医疗、政务等行业的具体应用场景及其带来的降本增效、提质增效等优势。最后，报告展望了大模型的发展趋势，强调了架构优化、行业数字化转型和可信发展的必要性。 适合人群：具备一定技术背景，特别是从事人工智能、大数据、云计算等领域工作的研发人员、管理人员和技术决策者。 使用场景及目标：①帮助企业和机构评估自身大模型应用的基础条件，明确业务转型需求；②指导大模型建设方案的设计和实施，确保技术选型的科学性和合理性；③提供应用部署和效能评估的具体方法，确保大模型在实际应用中的稳定性和高效性；④建立健全大模型的运营管理体系，保障业务的高效稳定开展。 其他说明：报告强调了大模型在推动各行业数字化转型中的重要作用，提出了未来大模型发展的重点方向，如架构优化、技术应用和可信发展。报告还呼吁社会各界共同关注大模型的安全可信问题，确保其与人类价值观的对齐，推动大模型的健康发展。
少儿编程scratch项目源代码文件案例素材-Scratch泡泡龙.zip
软考初级程序员是中国计算机技术与软件专业技术资格（水平）考试中的一个重要级别，主要面向打算进入IT行业的初学者或初级程序员。这个级别的考试旨在测试考生的基础编程能力、计算机基础知识以及解决问题的能力。历年真题是备考的重要参考资料，可以帮助考生了解考试的题型、难度以及考点。 在"软考初级程序员09-18年真题及答案解析"的压缩包中，包含了从2009年至2018年上半年的所有程序员考试真题。这些真题涵盖了多个方面，包括但不限于： 1. **基础编程语言**：如C语言、Java、Python等，主要考察基本语法、数据类型、控制结构、函数使用等方面。 2. **数据结构与算法**：如数组、链表、栈、队列、树、图等，以及排序算法（冒泡、选择、插入、快速、归并等）和查找算法（线性查找、二分查找等）。 3. **计算机系统知识**：包括计算机组成原理、操作系统、网络基础知识，例如CPU结构、内存管理、进程与线程、网络协议等。 4. **数据库基础**：SQL语言的基本操作，如增删改查、子查询、联接操作、索引等。 5. **软件工程与项目管理**：软件生命周期、需求分析、设计原则、测试方法、版本控制等。 6. **法律法规与职业道德**：涉及知识产权、合同法、信息安全与隐私保护等。 每份真题后的答案解析部分，是对题目答案的详细解释，通常包括解题思路、关键步骤以及知识点的扩展。通过阅读解析，考生不仅能知道自己答案的正确与否，还能深入理解相关知识点，提高自己的分析和解决问题的能力。 在准备软考初级程序员考试时，考生应充分利用这些真题资源，进行模拟练习，掌握各类题目的解答技巧。同时，考生还需要广泛阅读教材，补充相关知识，提高对理论的理解。此外，多做编程实践，提高实际编程能力，也是非常重要的。 总结来说，这个压缩包是备考软考初级程序员的宝贵资料，它能帮助考生熟悉考试形式，了解重
内容概要：本文详细介绍了如何在Zynq扩展口上使用FPGA和W5500实现稳定的TCP网络通信。作者通过一系列实验和技术手段，解决了多个实际问题，最终实现了零丢包的数据回环处理。主要内容包括：硬件搭建（SPI接口配置）、数据回环处理（双时钟域流水线）、压力测试（信号抓波形和防抖处理）、多路复用扩展以及上位机测试脚本的编写。文中提供了大量Verilog代码片段，展示了具体实现细节。 适合人群：具备一定FPGA开发经验的工程师，尤其是对TCP/IP协议栈感兴趣的嵌入式系统开发者。 使用场景及目标：适用于需要高性能、低延迟网络通信的应用场景，如工业控制系统、实时数据采集等。目标是帮助读者掌握在FPGA上实现高效TCP通信的方法和技术。 其他说明：文章不仅提供了详细的代码实现，还分享了许多实践经验，如SPI时钟优化、CS信号防抖、FIFO深度选择等。此外，作者还讨论了未来可能的改进方向，如UDP组播和QoS优先级控制。
内容概要：本文探讨了在汽车动力学研究和自动驾驶领域中，使用无迹扩展卡尔曼滤波（UKF/EKF）在Matlab/Simulink环境中对路面附着系数进行估计的方法。文中介绍了选择Matlab/Simulink的原因及其强大功能，详细解析了7自由度整车模型的构建，以及UKF和EKF的具体实现方式。UKF通过非线性处理和sigma点传播概率分布，适用于复杂工况；EKF则通过线性化处理，更适合计算资源有限的场景。两者在不同路面条件下表现出各自的优劣，如UKF在突变路面下表现更好，而EKF在不变路面上效率更高。此外，还讨论了调参技巧、工程实现细节及实际测试结果。 适用人群：从事汽车动力学研究、自动驾驶技术研发的专业人士，尤其是对非线性滤波算法感兴趣的研究人员和技术开发者。 使用场景及目标：①用于车辆稳定性控制系统中，提高行驶安全性；②优化滤波算法性能，平衡精度与实时性；③为复杂工况下的路面附着系数估计提供解决方案。 其他说明：文章不仅提供了理论分析，还包括大量代码示例和实践经验分享，有助于读者深入理解和实际应用。
内容概要：本文详细介绍了如何使用三菱PLC（以FX3U为例）和显控触摸屏实现定长送料系统的三种核心功能：点动、相对定位和绝对定位。文章从硬件连接开始，逐步讲解了每种功能的具体实现方法，包括梯形图编程、参数设置以及触摸屏交互设计。特别强调了伺服和步进电机的应用，并提供了调试技巧和注意事项，确保系统稳定可靠。 适合人群：从事工业自动化领域的工程师和技术人员，尤其是那些需要掌握PLC编程和伺服/步进电机控制的人群。 使用场景及目标：适用于各类需要精确控制物料输送的生产设备，如包装机、裁切设备等。目标是帮助工程师快速搭建稳定的定长送料系统，提高生产效率和产品质量。 其他说明：文中还分享了一些实战经验，如软限位设置、急停回路设计、电子齿轮比计算等，有助于解决实际应用中的常见问题。
内容概要：本文详细介绍了一个基于51单片机的音乐盒项目，涵盖从原理到实践的全过程。首先解释了音乐产生的基本原理，即通过控制I/O口输出不同频率的方波驱动蜂鸣器发声。接着介绍了原理图设计，重点描述了51单片机与其他组件如蜂鸣器、按键等的连接方式。然后讲解了Protues仿真工具的应用，强调其在硬件电路搭建前进行验证的重要性。最后深入剖析了程序源码，包括音符频率表、节拍编码、延时函数、播放音符和音乐的函数以及主函数的具体实现。 适合人群：对单片机开发感兴趣的初学者或有一定经验的研发人员。 使用场景及目标：适用于希望深入了解51单片机工作原理及其应用的人群，特别是那些想要亲手制作一个能够播放多首曲目的音乐盒爱好者。通过该项目的学习，不仅可以掌握单片机的基本编程技能，还可以提高解决实际问题的能力。 其他说明：文中提供了详细的代码注释和技术细节，帮助读者更好地理解和实现项目。此外，还分享了一些实用的小贴士，如如何避免常见错误、优化性能等。
子查询练习题，多练习总没有坏处，不知道凑没凑够十一个字