标签：使用 strong 文件 问题 代码 c++ .net 设计
分析问题
可能读者的固有思维认为.NET中所有的类型都必须继承自System.Object，这样的认识过于绝对，且不完全正确。在.NET中，.NET设计小组为中间语言的编译器ILasm.exe添加了noautoinherit开关，当这个开关被打开时，编译器将不会默认年地把类型认为继承自System.Object。
首先介绍一下中间语言的编译工具：ILasm.exe。这是.NET Framework提供的一个编译工具，它的作用是把中间语言（MSIL）编译成可执行的PE文件。该工具非常有用，它不仅使程序员有机会能够直接编写中间语言并且编译成PE文件，而且提供了另外一种部署方式，即手动地编译所有的中间代码并且直接部署最终的机器代码。
如果程序员用的开发语言是C#，则在编译成中间语言时，类型已经被默认地添加了继承自System.Object的代码，这时候无论是否为ILasm.exe打开noautoinherit开关，生成的类型都将继承自System.Object，但如果程序员手动地编写了不继承自System.Object类型的中间代码，并且使用noautoinherit开关，则会生成一个特别的无父类的类型。
在全托管单语言的编程环境下，设计不继承自System.Object的类型不会带来任何好处，相反地，它会导致种种违反常规的运行错误。不继承自System.Object的类型不符合CLS的规范，并且在正常的程序中出现意外的异常。但是为了融合其他编程语言（比如C++/CLI），这样的内建机制有着其独特的作用。在通常情况下，读者不需要也不应该建立不继承自System.Object的类型，但需要注意的是，在特殊的环境下任何代码不能作出对象类型继承自System.Object的保证，甚至于不能相信as、is等类型检查语法的结果。程序员唯一可以并且必须做得就是：时刻准备着捕捉各种意料之外的异常。
答案
通过运用ILasm.exe的noautoinherit开关，可以生成不从System.Object继承的类型，这种类型不是安全的类型，也不建议使用。但是，这样机制的存在，促使程序员在编写代码时不能随意地把任何对象默认地看成System.Object的子类类型。
是否存在不继承自System.Object类型的类,布布扣,bubuko.com
标签：使用 strong 文件 问题 代码 c++ .net 设计
原文地址：http://www.cnblogs.com/wangjinpeng-study/p/3913854.html
