解析C++/CLI之头文件、内联函数与数组 | |||||||||
---|---|---|---|---|---|---|---|---|---|
http://www.sina.com.cn 2006年10月23日 09:08 天极yesky | |||||||||
作者:谢启东编译 头文件与函数声明
在编译及链接任何程序集时,都隐含不使用头文件,且程序集所依赖的所有其他程序集都必须是已编译及链接过的。 内联函数 在Point中,每个成员函数的定义都有意写成了inline(内联),除了增加定义的灵活性外,还可把代码保持在同一源文件中,使成员函数不能在类型定义本身之外的另一文件中被定义。 编写内联函数的传统方法是把某个函数都声明为inline,其对编译器来说是一个提示,让编译器在适当的时候对它进行内联化处理,是典型的以空间换时间做法。然而,在头文件定义中使用内联函数,这种形式的优化对编译来说,却非常有限。当Point类编译时,编译器会把类型内部对成员函数的调用内联化,例如,Point定义中所有X与Y属性的get与set方法都会被内联化。 那么,如果要在其他程序集的代码中使用Point,又会怎么样呢?所有对Point成员函数的调用都会因此内联化吗?理论上来说,是的,毕竟,为编译应用程序代码,编译器需要访问Point程序集,故此它非常清楚既定的成员函数是怎样实现的,由此也会允许对这些函数的引用进行优化。 来看一下GetHashCode,从它简单的内容来看,似乎很适合进行内联化。现假定从外部另一程序集中对它的所有调用都是内联化的,那么,接下来,编译器很可能会使用不同的算法重新实现此函数。但如果未重新生成此外部程序集,它将会继续使用内联的hashcode算法,而不是新的版本。因为这通常都不是所期望发生的行为,所以要尽量避免跨程序集边界的内联,那么,也就不会对X与Y属性那些不重要的get与set方法进行内联了。 可幸的是,优化还可在编译之外进行,比如说,在最简单的执行模式中,每次一个程序只要一运行,它的CIL指令就会被执行。然而,一个即时编译器(JIT)会识别出特定的编码范式,并进行各种优化,其中就包含了代码内联。而那些大型、复杂的程序,会在每次安装时,都编译为本地代码,以这种方法,就不必在每次程序执行时,进行优化了。 GetHashCode的定义是没有声明为内联的,如果声明了,那对此头文件的多个包含,会导致同一名称的多次定义,就别指望链接器不会提出"抗议"了。但是要知道,这种方法是用于程序集而不是头文件的,所以一般不会产生此类错误,在程序集中只有这个函数的唯一定义。一般说来,在上下文中使用inline,出于自愿而不是强迫,事实上,在本例中,是不可使用的,因为声明为override的任何函数,都不能再标上inline。 遵从CLS 如果属性中的set与get方法使用了与众不同的可访问性,那么,就会阻碍语言间协同工作的能力。CLI的其中一个目标就是在无须主动请求的情况下,提升语言间的互操作性,为此,它定义了一个通用语言规范(CLS [1])和一套CLS规则,例如,第25条规则写明:"属性之访问性存取程序应为一致。" 当为CLI环境下实现一种类型时,需要考虑,是否导出了类型的多个方面,如成员函数签名等等,举例来讲,并不是所有基于CLI的语言都支持无符号整数及指针类型,又或只有一小部分语言能理解const与volatile。 CLS要求不具备某种特性的语言也能以函数调用的语法,来访问它们,正因为这个原因,属性X的存取程序在元数据中被各自称为get_X与set_X,类似地,对操作符函数,也有相应的元数据名,所以它们也能被那些没有操作符重载概念的语言所调用。
|