头文件与函数声明
在传统C++的设计与实现中，你可对需建模的每种类型进行定义，并把定义放在各自的头文件中；而头文件中，一般会包含类型名、成员名、及相关小型成员函数的内联定义。
与各个单独编译的源文件是通过头文件来共享信息不同，在C++/CLI中，这些信息是通过程序集来共享的。就拿常举例的Point类来说，它单独编译，并生成了一个名为"Point.dll"的程序集。任何需要某种类型定义的应用程序，都必须编译和链接带有此类型的程序集，这同时也要求此DLL形式的程序集中有完整的类型定义；同样，在类型中所有声明的函数也必须被定义，否则，链接器将会报告错误。
举例来说，你可以在Point类中声明成员函数GetHashCode，并在类外定义它，但必须在同一源文件中（见例1）。但是，若把此成员函数的定义放在一个单独的源文件中却不行，即便源文件是作为同一程序集的输入、与Point.cpp同时编译也不行，因为编译这样一个文件需要访问程序集Point.dll，而这正好是此编译过程要生成的程序集。（此处假定在函数定义时未使用inline，这将在后面讨论。）
例1：
public ref class Point
{
...
virtual int GetHashCode() override;
};
int Point::GetHashCode() override
{
return X ^ (Y << 1);
} |
在编译及链接任何程序集时，都隐含不使用头文件，且程序集所依赖的所有其他程序集都必须是已编译及链接过的。
内联函数 在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，类似地，对操作符函数，也有相应的元数据名，所以它们也能被那些没有操作符重载概念的语言所调用。
京公网安备 11010802021500号