您正在看的VC.NET教程是:解析C++/CLI之头文件、内联函数与数组。
头文件与函数声明
在传统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，类似地，对操作符函数，也有相应的元数据名，所以它们也能被那些没有操作符重载概念的语言所调用。
Equals函数 PK ==操作符
对一个引用类而言，相等性比较是通过一个名为Equals的函数，而不是重载 == 操作符来实现的。但是，还是可以重载此操作符的，见例2。
例2：
public ref class Point
{
...
static bool operator==(Point^ p1, Point^ p2)
{
Object^ o1 = p1;
Object^ o2 = p2;
/*1*/ if (o1 == nullptr || o2 == nullptr)
{
return false;
}
if (o1 == o2) //在测试自身吗？
{
return true;
}
if (p1->GetType() == p2->GetType())
{
return (p1->X == p2->X) && (p1->Y == p2->Y);
}
return false;
}
};
在标号1中，指明了不接受空值的句柄，但是，此处如果用p1与p2来代替o1与o2，就会造成自身的递归调用，因此，必须隐式转换为Object^。为遵从CLS，在此把函数标为static。（非静态操作符函数不符合CLS。）
除了句柄符号之外，这个函数与用传统C++编写起来非常类似，然而，最大的不同之处恰恰在于此操作符的使用，如果有这样一种情况，(p == q)，p与q都是Point^类型，问题在于，代码的阅读者可能会认为此处是在比较两个句柄，但实际上，是在比较这些句柄引用的Point。为明确地比较句柄，需要这样编写代码：
if (static_cast<Object^>(p1) == static_cast<Object^>(p2))
虽然也可为Point类提供 == 操作符函数，但仍必须提供Equals，否则，其他人对一个Point调用Equals时，就会转到System::Object中的相应函数，而其比较的是引用相等性，而不是值相等性。也就是说，如果指定Object的实例与当前实例为同一实例，它返回true，否则，返回false。
CLI数组
因为标准C++中也存在数组，它们与C语言中的数组也非常类似，也具有同样的利弊关系，即，它们都在编译时分配空间，有固定大小，且没有强制检查数组边界。多维数组并不真正存在，实际上，它们都是数组的数组，或数组的数组的数组等等，在此，我们把这类数组称为"本地数组"。
而在CLI中，数组则为对象，并分配在垃圾回收堆上，它们的大小在编译时可以为未知状态，且在运行时会自动进行数组边界检查，还支持真正的多维数组。同样地，就需要新的语法来表示这类CLI数组。
例3：
int main()
{
/*1*/ array<int>^ numbers = gcnew array<int>(5) {10, 20, 30, 40};
Display1DArray("numbers", numbers);
/*2*/ array<Point^>^ poi
