一、绪论

当微软推出VS.NET7实现了可扩展的托管C++后，C++程序员们反映不一。尽管大部分的程序员对于能够继续使用C++感到很欣慰，但几乎所有的人对于托管C++提供的晦涩语法感到很痛苦。微软明显从反馈中感觉到托管C++不是那么成功。

2003年10月6日，ECMA（欧洲计算机制造商协会）宣布成立专家组，负责结合ISO标准C++与通用语言，开发一个可扩展语言的标准，这个新的可扩展语言被称为C++/CLI标准。这个标准将被VS.NET2005的C++编译器支持。

二、老语法存在的问题

1、晦涩繁琐的语法和文法--这两个"双重底线"问题加重了阅读的负担。

2、二流的CLI支持--相对与C#与VB.NET，MC++使用不方便的工作区来提供CLI支持，例如，它没有一个一一对应的结构来列举.NET的集合。

3、C++与.NET粗陋地结合--对于CLI类型，你不能使用C++的特色，例如模板；同样，对于C++类型，你不能使用CLI的特色，例如碎片帐集。

4、令人混淆的指针--非托管的C++的指针及托管的引用指针都使用*语法，这非常令人混淆，因为-gc指针与托管指针在本质和行为上完全不同。

5、MFC编译器不能产生可校验的代码。

三、C++/CLI给我们提供了什么？

1、优雅流畅的语法和文法--C++/CLI为C++开发人员书写托管代码提供了一种非常自然的感觉，并且它提供了非托管代码到托管代码的平滑过度。以前所谓的"双重底线"问题现在已经荡然无存。

2、一流的CLI支持--CLI特色，例如属性、碎片集合和属类得到了直接支持，此外，C++/CLI还准许将这些特色用于本地非托管的类。

3、一流的C++类支持--C++特色，例如模板和析构函数对于拖管和非拖管类继续有效。实际上，C++/CLI是你可以"表面上"在栈或C++本地堆上声明一个.NET类型唯一的.NET语言。

4、在.NET与C++之间的沟壑上架起了一座桥梁--C++开发人员在抨击BCL时不再象离开水的鱼。

5、C++/CLI编译器产生的可执行文件完全是可校验的。

四、"Hello World"小程序

using namespace System; void _tmain() { Console::WriteLine("Hello World"); }

上述代码除了不需要引用mscorlib.dll库外，与老的语法没有太大的区别，因为无论你什么时候使用/clr进行编辑，编译器都可以暗中进行引用（现在默认的是/clr:newSyntax）。

五、句柄

与老的语法主要的混淆是我们习惯于使用*符号来声明拖管引用或非拖管指针，在C++/CLI里微软引入了句柄的概念。

void _tmain() { //The ^ punctuator represents a handle String^ str = "Hello World"; Console::WriteLine(str); }

^符号代表一个托管对象（声明时看上去象个帽子），按照CLI的规定，句柄代表一个拖管对象的引用。句柄在CLI中是新的语法，相当于C++中的-gc指针。句柄与指针不再混淆，在本质上两者完全不同。

六、句柄与指针是怎样区分开来的？

1、指针声明时使用*符号，而句柄使用^符号。

2、句柄是针对拖管堆上对象的拖管引用，而指针仅仅指向内存中的一个地址。

3、指针很稳定，GC循环不会影响到它；句柄在基于GC或内存紧张的情况下，可以指向不同的内存位置。

4、对于指针，程序开发人员必须"显式"地删除，否则会面临泄露的危险，而对于句柄，是否进行显式删除则完全根据程序人员的爱好了。

5、句柄一定要指向一个具体的类型，即所谓的类型安全性，而指针明显不是这样，你决不可以将一个句柄指向Void^类型。

6、正如new操作符返回一个指针一样，gcnew返回一个句柄。

七、CLR对象示例

void _tmain() { String^ str = gcnew String("Hello World"); Object^ o1 = gcnew Object(); Console::WriteLine(str); }

关键字gcnew用来实例化一个CLI对象，而且它返回一个指向在CLR堆上的对象的句柄，gcnew的优点在于它可以方便的让我们区分拖管和非拖管的实例对象。

大部分情况下，gcnew关键字和^操作符提供了你用来进行BCL的一切手段，但是很明显你需要创建和声明属于自己的拖管类和接口。

八、声明类型

CLR类型有一个形容词前缀用来说明类型的种类，下面是C++/CLI中的类型声明示例：

1、 CLR types o Reference types § ref class RefClass; § ref struct RefClass; 2、 Value types § value class ValClass; § value struct ValClass; o Interfaces § interface class IType; § interface struct IType; o Enumerations § enum class Color; § enum struct Color; 3、 Native types o class Native; o struct Native; 示例： using namespace System; interface class IDog { void Bark(); }; ref class Dog : IDog { public: void Bark() { Console::WriteLine("Bow wow wow"); } }; void _tmain() { Dog^ d = gcnew Dog(); d->Bark(); }

上述程序中的代码与老的C++语言相比看上去非常简洁，在以往的C++代码中，至少要用到-gc和-interface这两个关键词。

九、装箱/拆箱操作

在C++/CLI中，加箱是隐含的，而且类型是安全的，一个二进制的拷贝被执行并在CLR堆上形成一个对象，去箱是显式的，仅仅需要使用reinterpret_cast操作符来解除引用。

void _tmain() { int z = 44; Object^ o = z; //implicit boxing int y = *reinterpret_cast<int^>(o); //unboxing Console::WriteLine(" ",o,z,y); z = 66; Console::WriteLine(" ",o,z,y); } // 输出结果如下： // 44 44 44 // 44 66 44

在上述代码中，"o"对象是一个加箱的拷贝，从第二个语句Console::WriteLine.的输出可以很明显地看到，它并没有涉及到int类型的整数值。

当你对一种数值类型进行加箱操作时，返回的对象记住了最初的数值类型。

void _tmain() { int z = 44; float f = 33.567; Object^ o1 = z; Object^ o2 = f; Console::WriteLine(o1->GetType()); Console::WriteLine(o2->GetType()); } // Output // System.Int32 // System.Single

因此不能对不同类型的对象进行去箱操作。

void _tmain() { int z = 44; float f = 33.567; Object^ o1 = z; Object^ o2 = f; int y = *reinterpret_cast<int^>(o2);//System.InvalidCastException float g = *reinterpret_cast<float^>(o1);//System.InvalidCastException }

如果你非尝试这么做，那么你将得到一个System.InvalidCastException。让我们来探讨一下完美的类型安全性，如果你要看内部代码，你将看到微软的内部箱在实际中的运用。例如：

void Box2() { float y=45; Object^ o1 = y; }

编译后的代码是：

.maxstack 1 .locals (float32 V_0, object V_1) ldnull stloc.1 ldc.r4 45. stloc.0 ldloc.0 box [mscorlib]System.Single stloc.1 ret

根据微软的内部文档，箱操作将未加工的类型转换为一个具体类型的实例，这项工作的完成通过创建一个新的对象并将数据拷贝到这个新分配的对象。

十、写在后面的话

为什么很多人已经可以使用C、C++、.NET来开发程序但还在积极学习C++/CLI呢，我想有四个方面的原因：

1、从编译器直到内层都还在支持C++代码；

2、C++/CLI对于其他标准来说无意是具有毁灭性地；

3、与生俱来的内部支持胜过所有其他CLI语言

4、所有在MFC中出现的下划线都已不再存在。

C++/CLI：第一流的CLI语言
2005-08-25 11:25 作者： 朱先忠编译 出处： 天极网 责任编辑：方舟

1. 简介

　　本文并不是为了奉承C++/CLI的辉煌，也不是为了贬低其它如C#或者VB.NET等语言，相反，这只是一个非官方的、以一个喜欢这种语言的非微软雇员身份来论证C++/CLI有它的自己的唯一的角色，可作为第一流的.NET编程语言。

　　一个不断在新闻组和技术论坛上出现的问题是，当象C#和VB.NET这样的语言更适合于这种用途时，为什么要使用C++来开发.NET应用软件。通常这样一些问题后面的评论说是，C++语法是怎样的复杂和令人费解，C++现在是怎样一种过时的语言，还有什么VS.NET设计者已不再像支持C#和VB.NET一样继续支持C++。其中一些猜疑是完全荒谬的，但有些说法部分正确。希望本文有助于澄清所有这些围绕C++/CLI语言及其在VS.NET语言层次中的地位的疑惑，神秘和不信任。请记住，本作者既不为微软工作也没有从微软那里取得报酬，只是想从技术上对C++/CLI作一评判。

　　2. 快速简洁的本机interop

　　除了P/Invoke机制可用在另外的象C#或VB.NET这样的语言外，C++提供了一种独有的interop机制，称作C++ interop。C++ interop比P/Invoke直观得多，因为你只是简单地#include需要的头文件，并与需要的库进行链接就能象在本机C++中一样调用任何函数。另外，它比P/Invoke速度快--这是很容易能证明的。现在，可争辩的是在实际应用软件的开发中，经由C++ interop获得的性能好处与花在用户接口交互、数据库存取、网络数据转储、复杂数学算法等方面的时间相比可以被忽略，但是事实是在有些情况下，甚至通过每次interop调用节省的几个纳秒也能给全局应用程序性能/响应造成巨大影响，这是绝对不能被忽视的。下面有两部分代码片断(一个是使用P/Invoke机制的C#程序，一个是使用C++ Interop机制的C++程序)，我分别记录了其各自代码重复执行消耗的时间(毫秒)。不管你如何解释这些数据，不管这会对你的应用程序产生什么影响，全是你的事。我仅打算事实性地指出，C++代码的执行速度要比C#(其中使用了较多的本机interop调用)快。

　　1) C#程序(使用P/Invoke)

[SuppressUnmanagedCodeSecurity] [DllImport("kernel32.dll")] static extern uint GetTickCount(); [SuppressUnmanagedCodeSecurity] [DllImport("kernel32.dll", SetLastError = true, CharSet = CharSet.Auto)] static extern uint GetWindowsDirectory( [Out] StringBuilder lpBuffer, uint uSize); static void Test(int x) { StringBuilder sb = new StringBuilder(512); for (int i = 0; i < x; i++) GetWindowsDirectory(sb, 511); } static void DoTest(int x) { uint init = GetTickCount(); Test(x); uint tot = GetTickCount() - init; Console.WriteLine("Took {0} milli-seconds for {1} iterations",tot, x); } static void Main(string[] args) { DoTest(50000);DoTest(500000);DoTest(1000000);DoTest(5000000); Console.ReadKey(true); }

　　2) C++程序(使用C++ Interop)

void Test(int x) { TCHAR buff[512]; for(int i=0; i<x; i++) GetWindowsDirectory(buff, 511); } void DoTest(int x) { DWORD init = GetTickCount(); Test(x); DWORD tot = GetTickCount() - init; Console::WriteLine("Took {0} milli-seconds for {1} iterations",tot, x); } int main(array<System::String ^> ^args) { DoTest(50000);DoTest(500000);DoTest(1000000);DoTest(5000000); Console::ReadKey(true); return 0; }

　　3) 速度比较

重复次数	C# 程序	C++程序
50,000	61	10
500,000	600	70
1,000,000	1162	140
5,000,000	6369	721

　　
　　其性能差别真是令人惊愕！这的确是说明为什么要使用C++/CLI的一个好理由，如果你在使用本机interop进行开发，那么性能！完全由于性能，我就将被迫借助本机interop来实现并非基于web的.NET应用程序。当然，为什么我想要使用.NET来开发需要大量本机interop技术的应用程序完全是另外一个问题。

　　如果你仍怀疑这种性能优势，有另外的理由来说明你为什么不得不使用C++/CLI而不是C#或VB.NET——源码膨胀！下面是一个C++函数的例子，它使用了IP帮助者API来枚举一台机器上的网络适配器并且列出与每个适配器相联系的所有IP地址。

　　4) 枚举n/w适配器的C++代码

void ShowAdapInfo() { PIP_ADAPTER_INFO pAdapterInfo = NULL; ULONG OutBufLen = 0; //得到需要的缓冲区大小 if(GetAdaptersInfo(NULL,&OutBufLen)==ERROR_BUFFER_OVERFLOW) { int divisor = sizeof IP_ADAPTER_INFO; #if _MSC_VER >= 1400 if( sizeof time_t == 8 ) divisor -= 8; #endif pAdapterInfo = new IP_ADAPTER_INFO[OutBufLen/divisor]; //取得适配器信息 if( GetAdaptersInfo(pAdapterInfo, &OutBufLen) != ERROR_SUCCESS ) {//调用失败 } else { int index = 0; while(pAdapterInfo) { Console::WriteLine(gcnew String(pAdapterInfo->Description)); Console::WriteLine("IP Address list : "); PIP_ADDR_STRING pIpStr = &pAdapterInfo->IpAddressList; while(pIpStr) { Console::WriteLine(gcnew tring(pIpStr->IpAddress.String)); pIpStr = pIpStr->Next; } pAdapterInfo = pAdapterInfo->Next; Console::WriteLine(); } } delete[] pAdapterInfo; } }

　　现在让我们看一个使用P/Invoke的C#版本。

　　5) 使用P/Invoke技术的C#版本

const int MAX_ADAPTER_NAME_LENGTH = 256; const int MAX_ADAPTER_DESCRIPTION_LENGTH = 128; const int MAX_ADAPTER_ADDRESS_LENGTH = 8; const int ERROR_BUFFER_OVERFLOW = 111; const int ERROR_SUCCESS = 0; [StructLayout(LayoutKind.Sequential, CharSet = CharSet.Ansi)] public struct IP_ADDRESS_STRING { [MarshalAs(UnmanagedType.ByValTStr, SizeConst = 16)] public string Address; } [StructLayout(LayoutKind.Sequential, CharSet = CharSet.Ansi)] public struct IP_ADDR_STRING { public IntPtr Next; public IP_ADDRESS_STRING IpAddress; public IP_ADDRESS_STRING Mask; public Int32 Context; } [StructLayout(LayoutKind.Sequential, CharSet = CharSet.Ansi)] public struct IP_ADAPTER_INFO { public IntPtr Next; public Int32 ComboIndex; [MarshalAs(UnmanagedType.ByValTStr, SizeConst = MAX_ADAPTER_NAME_LENGTH + 4)] public string AdapterName; [MarshalAs(UnmanagedType.ByValTStr, SizeConst = MAX_ADAPTER_DESCRIPTION_LENGTH + 4)] public string AdapterDescription; public UInt32 AddressLength; [MarshalAs(UnmanagedType.ByValArray, SizeConst = MAX_ADAPTER_ADDRESS_LENGTH)] public byte[] Address; public Int32 Index; public UInt32 Type; public UInt32 DhcpEnabled; public IntPtr CurrentIpAddress; public IP_ADDR_STRING IpAddressList; public IP_ADDR_STRING GatewayList; public IP_ADDR_STRING DhcpServer; public bool HaveWins; public IP_ADDR_STRING PrimaryWinsServer; public IP_ADDR_STRING SecondaryWinsServer; public Int32 LeaseObtained; public Int32 LeaseExpires; } [DllImport("iphlpapi.dll", CharSet = CharSet.Ansi)] public static extern int GetAdaptersInfo(IntPtr pAdapterInfo, ref int pBufOutLen); static void ShowAdapInfo() { int OutBufLen = 0; //得到需要的缓冲区大小 if( GetAdaptersInfo(IntPtr.Zero, ref OutBufLen) == ERROR_BUFFER_OVERFLOW ) { IntPtr pAdapterInfo = Marshal.AllocHGlobal(OutBufLen); //取得适配器信息 if( GetAdaptersInfo(pAdapterInfo, ref OutBufLen) != ERROR_SUCCESS ) { //调用失败了 } else{ while(pAdapterInfo != IntPtr.Zero) { IP_ADAPTER_INFO adapinfo = (IP_ADAPTER_INFO)Marshal.PtrToStructure( pAdapterInfo, typeof(IP_ADAPTER_INFO)); Console.WriteLine(adapinfo.AdapterDescription); Console.WriteLine("IP Address list : "); IP_ADDR_STRING pIpStr = adapinfo.IpAddressList; while (true){ Console.WriteLine(pIpStr.IpAddress.Address); IntPtr pNext = pIpStr.Next; if (pNext == IntPtr.Zero) break; pIpStr = (IP_ADDR_STRING)Marshal.PtrToStructure( pNext, typeof(IP_ADDR_STRING)); } pAdapterInfo = adapinfo.Next; Console.WriteLine(); } } Marshal.FreeHGlobal(pAdapterInfo); } }

3. 栈语义和确定性的析构

　　C++经由栈语义模仿给了我们确定性的析构。简言之，栈语义是Dispose模式的良好的语法替代品。但是它在语义上比C# using块语法更直观些。请看下列的C#和C++代码段（都做一样的事情-连接两个文件的内容并把它写到第三个文件中）。

　　1) C#代码--使用块语义

public static void ConcatFilestoFile(String file1, String file2, String outfile) { String str; try{ using (StreamReader tr1 = new StreamReader(file1)) { using (StreamReader tr2 = new StreamReader(file2)) { using (StreamWriter sw = new StreamWriter(outfile)) { while ((str = tr1.ReadLine()) != null) sw.WriteLine(str); while ((str = tr2.ReadLine()) != null) sw.WriteLine(str); } } } } catch (Exception e) { Console.WriteLine(e.Message); } }

　　2) C++代码--栈语义

static void ConcatFilestoFile(String^ file1, String^ file2, String^ outfile) { String^ str; try{ StreamReader tr1(file1); StreamReader tr2(file2); StreamWriter sw(outfile); while(str = tr1.ReadLine()) sw.WriteLine(str); while(str = tr2.ReadLine()) sw.WriteLine(str); } catch(Exception^ e) { Console::WriteLine(e->Message); } }

　　C#代码与相等的C++ 代码相比不仅免不了冗长，而且using块语法让程序员自己明确地指定他想在哪儿调用Dispose（using块的结束处），而使用C++/CLI的栈语义，只需让编译器使用常规的范围规则来处理它即可。事实上，这使得在C#中修改代码比在C++中更乏味-作为一实例，让我们修改这些代码以便即使仅存在一个输入文件也能创建输出文件。请看下面修改后的C#和C++代码。

　　3) 修改后的C#代码

public static void ConcatFilestoFile(String file1, String file2, String outfile) { String str; try{ using (StreamWriter sw = new StreamWriter(outfile)) { try{ using (StreamReader tr1 = new StreamReader(file1)) { while ((str = tr1.ReadLine()) != null) sw.WriteLine(str); } } catch (Exception) { } using (StreamReader tr2 = new StreamReader(file2)) { while ((str = tr2.ReadLine()) != null) sw.WriteLine(str); } } } catch (Exception e){ } }

　　把针对StreamWriter的using块放到顶层需要重新调整using块结构--这在上面情况下显然不是个大问题，但是对于实际开发中的修改，这可能是相当模糊的且易导致逻辑错误的。

　　4) 修改后的C++代码

static void ConcatFilestoFile(String^ file1, String^ file2, String^ outfile) { String^ str; try{ StreamWriter sw(outfile); try{ StreamReader tr1(file1); while(str = tr1.ReadLine()) sw.WriteLine(str); } catch(Exception^){} StreamReader tr2(file2); while(str = tr2.ReadLine()) sw.WriteLine(str); } catch(Exception^){} }

　　这样不是比在C#中的做更容易些吗？我恰好把StreamWriter声明移到了顶部并增加了一个额外的try块，就这些。甚至对于象在我的示例代码片断中的琐碎事情，如果所涉及的复杂性在C++中大大减少，那么，当你工作于更大的工程时你能想象使用栈语义对你的编码效率千万的影响。

　　还不确信？好，让我们看一下成员对象和它们的析构吧。Imagine CLI GC类R1和R2，二者都实现了Idisposable接口且都有函数F()，还有一个CLI GC类R，它有R1和R2成员和一个函数F()-它内部地调用R1和R2上的F()成员函数。让我们先看C#实现。

　　5) 一个disposable类继承层次的C#实现

class R1 : IDisposable{ public void Dispose() { } public void F() { } } class R2 : IDisposable{ public void Dispose() { } public void F() { } } class R : IDisposable{ R1 m_r1 = new R1(); R2 m_r2 = new R2(); public void Dispose() { m_r1.Dispose(); m_r2.Dispose(); } public void F() { m_r1.F(); m_r2.F(); } public static void CallR() { using(R r = new R()) {r.F();} } }

　　这里有几件事情要做：必须为每个disposable 类手工实现IDisposable接口，对于具有成员R1和R2的类R，Dispose方法也需要调用成员类上的Dispose。现在让我们分析上面几个类的C++实现。

　　6) 等价的C++实现

ref class R1 { public: ~R1(){} void F(){} }; ref class R2 { public: ~R2(){} void F(){} }; ref class R { R1 m_r1; R2 m_r2; public: ~R(){} void F() { m_r1.F(); m_r2.F(); } static void CallR() { R r; r.F(); } };

　　注意，这里不再有手工的Idisposable接口实现(我们的类中仅建立了析构器)而且最好的部分--类R的析构器(Dispose方法)并没有在该类可能含有的可释放的成员上调用Dispose-它没有必要这样做，编译器自动为之生成所有的代码！

4. 混合类型

　　我们知道，C++支持本机类型-总是如此；C++支持CLI类型-本文正是特别强调这一点；它还支持混合类型-具有CLI成员的本机类型和具有本机成员的CLI类型！请尽管考虑所有你能的可能需求。

　　注意，谈到Whidbey，混合类型实现还不完整；就我从Brandon，Herb和Ronald发表的材料的理解得知，存在这种相当酷的类型--统一模型，它将在Orcas中实现--你能够在本机C++堆上new/delete CLI类型，而且也能够在CLI堆上gcnew/delete本机类型。但既然这是Whidbey以后的东西，本文不讨论统一模型。

　　在我谈论你何时使用混合类型以前，我想向你说明什么是混合类型。如果你理解混合类型，请跳过下面几段。这里引用Brandon Bray的说法："一种混合类型，或者是本机类ref类（需要有对象成员），或者是通过声明或继承被分配在垃圾回收堆或本机堆上的。"因此如果你有一个托管类型或者有一个有托管成员的本机类型，你就有了一个混合类型。VC++ Whidbey不直接支持混合类型(统一类型模型是一种Whidbey之后的概念)，但是它给我们划定了实现混合类型的条件。让我们开始讨论包含托管成员的本机类型。

ref class R { public: void F(){} //假定 non-trivial ctor/dtor R(){} ~R(){} };

　　在我的例子中，设想该托管类型R有一个non-trivial构造器和一个non-trivial析构器。

class Native { private: gcroot<R^> m_ref; public: Native(): m_ref(gcnew R()){} ~Native() { delete m_ref; } void DoF() { m_ref->F(); } };

　　既然，我不能在我的类中拥有一个R成员，我使用了gcroot模板类(在gcroot.h中声明，但是你要用"#include vcclr.h")，它包装了System::Runtime::InteropServices::GCHandle结构。它是个象类一样的灵敏指针，它重载了运算符->以返回用作模板参数的托管类型。因此在上面类中，我可以使用m_ref，就好象我已经声明它是R^，而且你能在DoF函数中看到这正在起作用。实际上你可以节省delete，这可以通过使用auto_gcroot(类似于std::auto_ptr，在msclr\auto_gcroot.h文件中声明)代替gcroot来实现。下面是一个更好些的使用auto_gcroot的实现。

class NativeEx { private: msclr::auto_gcroot<R^> m_ref; public: NativeEx() : m_ref(gcnew R()){} void DoF() { m_ref->F(); } };

　　下面让我们看相反的情形：一个CLI类的本机成员。

ref class Managed { private: Native* m_nat; public: Managed():m_nat(new Native()){ } ~Managed() { delete m_nat; } !Managed() { delete m_nat; #ifdef _DEBUG throw gcnew Exception("Oh, finalizer got called!"); #endif } void DoF() { m_nat->DoF(); } };

　　我不能定义一个Native对象来作为一个ref类成员，因此需要使用一个Native*对象来代替。我在构造器中new该Native对象，然后在析构器和finalizer中delete它。如果你运行该工程的调试版，在执行到finalizer时将抛出一个异常- 因此开发者可以马上添加一个对delete的调用或为他的CLI类型使用栈语义技术。奇怪的是，库开发小组没有建立一个gcroot的反向实现-但这不是个大问题，我们可以自己写。

template<typename T> ref class nativeroot { T* m_t; public: nativeroot():m_t(new T){} nativeroot(T* t):m_t(t){} T* operator->() { return m_t; } protected: ~nativeroot() { delete m_t; } !nativeroot() { delete m_t; #ifdef _DEBUG throw gcnew Exception("Uh oh, finalizer got called!"); #endif } };

　　这仅是个相当简单的灵敏指针实现，就象一个负责本机对象分配/回收的ref类。不管怎样，借助nativeroot模板类，我们可以如下修改托管类：

ref class ManagedEx { private: nativeroot<Native> m_nat; public: void DoF() { m_nat->DoF(); } };

　　好，关于混合类型的最大问题是什么呢？你可能问。最大问题是，现在你能混合使用你的MFC、ATL、WTL、STL代码仓库和.NET框架，并用可能的最直接的方式-只需写你的混合模式代码并编译实现!你可以建立在一个DLL库中建立MFC 类，然后建立一个.NET应用程序来调用这个DLL，还需要把.NET类成员添加到你的MFC类（也实现可以相反的情况）。

　　作为一例，设想你有一MFC对话框--它通过一个多行的编辑框接受来自用户的数据-现在，你有一新的要求-显示一个只读编辑框，它将显示当前在该多行编辑框中文本的md5哈希结果。你的队友正在悲叹他们将必须花费几个小时钻研crypto API，而你的上司在担忧你们可能必须要买一个第三方加密库；那正是你在他们面前树立形象的时候，你宣布你将在15分钟内做完这项任务。下面是解决的办法：

　　添加一个新的编辑框到你的对话框资源中，并且添加相应的DDX变量。选择/clr编译模式并且添加下列代码到你的对话框的头文件中：

#include <msclr\auto_gcroot.h> using namespace System::Security::Cryptography;

　　使用auto_gcroot模板来声明一个MD5CryptoServiceProvider成员：

protected: msclr::auto_gcroot<MD5CryptoServiceProvider^> md5;

　　在OnInitDialog过程中，gcnew MD5CryptoServiceProvider成员。

md5 = gcnew MD5CryptoServiceProvider();

　　并且为多行编辑框添加一个EN_CHANGE处理器：

void CXxxxxxDlg::OnEnChangeEdit1() { using namespace System; CString str; m_mesgedit.GetWindowText(str); array<Byte>^ data = gcnew array<Byte>(str.GetLength()); for(int i=0; i<str.GetLength(); i++) data[i] = static_cast<Byte>(str[i]); array<Byte>^ hash = md5->ComputeHash(data); CString strhash; for each(Byte b in hash) { str.Format(_T("%2X "),b); strhash += str; } m_md5edit.SetWindowText(strhash); }

　　这里使用了混合类型：一个本机Cdialog派生类，该类含有一个MD5CryptoServiceProvider成员(CLI类型)。你可以轻易地试验相反的情况（如早期的代码片断已显示的）——可以建立一个Windows表单应用程序而且可能想利用一个本机类库--这不成问题，使用上面定义的模板nativeroot即可。

5. 托管模板

　　也许你对泛型的概念已很清楚了，它帮助你避免进入C++的模板梦魇，它是实现模板的最佳方式，等等。好，假设这些全部正确，C++/CLI支持泛型就象任何其它CLI语言一样-但是它有而其它一些CLI语言还没有的是它还支持托管模板-也就是模板化的ref和value类。如果你以前从未使用过模板，你不能一下欣赏这么多优点，但是如果你有模板使用背景而且你已发现了泛型中存在的可能限制你编码的方式，托管模板将会大大减轻你的负担。你能联合使用泛型和模板- 事实上有可能用一个托管类型的模板参数来实例化一个泛型类型(尽管相反的情形是不可能的，因为运行时刻实例化由泛型所用)。STL.NET (或STL/CLR)以后讨论，请很好地利用泛型和托管模板的混合编程吧。

　　泛型使用的子类型约束机制将防止你写出下面的代码：

generic<typename T> T Add(T t1, T t2) { return t1 + t2; }

　　编译错误：

error C2676: binary ’+’ : ’T’ does not define this operator or a conversion to a type acceptable to the predefined operator

　　现在请看相应的模板版本：

template<typename T> T Add(T t1, T t2) { return t1 + t2; }

　　那么就可以这样做：

int x1 = 10, x2 = 20; int xsum = Add<int>(x1, x2);

　　还可以这样做：

ref class R { int x; public: R(int n):x(n){} R^ operator+(R^ r) { return gcnew R(x + r->x); } }; //... R^ r1 = gcnew R(10); R^ r2 = gcnew R(20); R^ rsum = Add<R^>(r1, r2);

　　这在一个象int的本机类型以及一个ref类型(只要ref类型有一个+运算符)情况下都能工作良好。这个泛型缺点不是一个调试错误或缺陷-它是设计造成的。泛型的实例化是在运行时通过调用配件集实现的，因此编译器不能确知一特定操作能被施行于一个泛型参数，除非它匹配一个子类型约束，因此编译器在定义泛型时解决这个问题。当你使用泛型时的另外一个妨碍是，它不会允许你使用非类型参数。下列泛型类定义不会编译：

generic<typename T, int x> ref class G{};

　　编译错：

error C2978: syntax error : expected ’typename’ or ’class’; found type ’int’; non-type parameters are not supported in generics

　　与托管模板相比较：

template<typename T, int x = 0> ref class R{};

　　如果你开始感激C++向你提供了泛型和托管模板，那么请看下面这一个例子：

template<typename T> ref class R{ public: void F() { Console::WriteLine("hey"); } }; template<> ref class R<int> { public: void F() { Console::WriteLine("int"); } };

　　你不能用泛型这样编码；否则，将产生：

　　编译错：error C2979: explicit specializations are not supported in generics

　　但可以在继承链中混合使用模板和泛型：

generic<typename T> ref class Base { public: void F1(T){} }; template<typename T> ref class Derived : Base<T> { public: void F2(T){} }; //... Derived<int> d; d.F1(10); d.F2(10);

　　最后，你不能从一个泛型参数类型派生一个泛型类。

　　下列代码不会成功编译：

generic<typename T> ref class R : T {};

　　error C3234: a generic class may not derive from a generic type parameter

　　模板让你这样做(好像你还不知道这些)：

ref class Base{ public: void F(){} }; generic<typename T> ref class R : T {}; //... R<Base> r1; r1.F();

　　这样，当你下次遇到对泛型的贬谤时，你就知道该怎么做了。

　　6. STL/CLR

　　当大量使用STL的C++开发者转向.NET1/1.1时一定感觉非常别扭，他们中的许多可能会放弃并转回到原来的本机编码。从技术上讲，你能结合.NET类型(using gcroot)使用本机STL，但是产生的结果代码可能相当低效，更不用说是丑陋了：

std::vector< gcroot<IntPtr> >* m_vec_hglobal; //... for each(gcroot<IntPtr> ptr in *m_vec_hglobal) { Marshal::FreeHGlobal(ptr);}

　　大概VC++小组考虑到了这些并决定在Whidbey以后，他们会提供STL.NET（或STL/CLR）并可以单独从网上下载。

　　你可能问为什么？Stan Lippman，在他的MSDN文章(STL.NET Primer)中给出了3条原因：

　　·可扩展性--STL设计把算法和容器隔离到自己的应用空间-也就是你可以有一组容器和一组算法，并且你能在任何一个容器上使用这些算法；同时你能在任何一个算法中使用这些容器。因此，如果你添加一种新的算法，你能在任何一种容器中使用它；同样，一个新的容器也可以与现有算法配合使用。

　　·统一性--所有核心C++开发者集中在一起，汇集起他们精妙的STL专长，再使用他们的专长则轻车熟路。要较好地使用STL需要花费时间-然而一旦你掌握了它，你就有了在.NET世界中使用你的技巧的明显优势。不是吗？

　　·性能--STL.NET通过使用实现泛型接口的托管模板实现。并且既然它的核心已用C++和托管模板编码，可以期盼它比在BCL上使用的泛型容器更具有性能优势。

　　使用过STL的人不需要任何示范，所以下面代码有益于以前没有使用过STL的人。

vector<String^> vecstr; vecstr.push_back("wally"); vecstr.push_back("nish"); vecstr.push_back("smitha"); vecstr.push_back("nivi"); deque<String^> deqstr; deqstr.push_back("wally"); deqstr.push_back("nish"); deqstr.push_back("smitha"); deqstr.push_back("nivi");

　　我使用了两个STL.NET容器-vector和deque，并装满两个容器，使其看起来相同(在两个容器中都使用了push_back)。现在，我将在两个容器上使用replace算法-我们再次看到，这些代码是很相同的。

replace(vecstr.begin(), vecstr.end(), gcnew String("nish"), gcnew String("jambo")); replace(deqstr.begin(), deqstr.end(), gcnew String("nish"), gcnew String("chris"));

　　这里特别要注意的是我使用了"同样"的算法--replace并在两个不同STL容器上使用相同的函数调用。这是当Stan谈及"可扩展性"时的意思。下面我用一个简单函数来证明：

template<typename ForwardIterator> void Capitalize( ForwardIterator first，ForwardIterator end) { for(ForwardIterator it = first; it < end; it++) *it = (*it)->ToUpper(); }

　　它遍历一个System::String^容器并把其中的每个字符串转化为大写。

Capitalize(vecstr.begin(), vecstr.end()); Capitalize(deqstr.begin(), deqstr.end()); for(vector<String^>::iterator it = vecstr.begin(); it < vecstr.end(); it++) Console::WriteLine(*it); Console::WriteLine(); for(deque<String^>::iterator it = deqstr.begin(); it < deqstr.end(); it++) Console::WriteLine(*it);

　　上面我的算法能够与vector和deque容器工作良好。至此，不再细谈；否则，guru站上的STL爱好者们会对我群起攻击，而非STL人可能感到厌烦。如果你还没使用过STL，可以参考有关资料。

7. 熟悉的语法

　　开发者经常迷恋他们所用的编程语言，而很少是出于实用的目的。还记得当微软宣布不再为VB6提供官方支持时，VB6人的反抗吗？非VB6人对此可能非常震惊，而老道的VB6人早已为他们的语言作好葬礼准备了。事实上，如果VB.NET从来没被发明，多数VB6人将会离开.NET，因为C#将会对他们非常陌生，而它的祖先就是C++。如今，许多VB.NET人可能已经转向了C#，但是他们不会从VB6直接转向C#；VB.NET起到一个桥梁作用让他们的思想脱离开原来VB6思想。相应地，如果微软仅发行VB.NET(而没有C#)，那么.NET可能成为了新的面向对象VB，且带有一个更大的类库-C++社团的人可能对此嗤之以鼻-他们甚至不会麻烦地检验.NET基础类库。为什么任何使用一种特定语言的开发者会对另外一个团体的使用另外开发语言的开发者嗤之以鼻？这不是我要回答的问题。--要回答该问题也许要先回答为什么有的人喜欢威士忌，有的人喜欢可口可乐，而还有人喜欢牛奶。所有我要说的是，对开发者来说，语法家族是个大问题。

　　你认为对于一个具有C++背景的人，下面的代码具有怎样的直觉性？

char[] arr =new char[128];

　　他/她可能回答的第一件事是，方括号放错了位置。下面这句又如何？

int y=arr.Length;

　　"呀!"-最可能的反映。现在把下面与前面相比较：

char natarr[128]; array<char>^ refarr=gcnew array<char>(128); int y=refarr->Length;

　　请注意声明一个本机数组和一个托管数组时的语法区别。这里不同的模板形式的语法可视化地告诫开发者这一事实--refarr并不是典型的C++数组而且它可能是某种CLI类的派生物(事实上确是如此)，所以极有可能可以把方法和属性应用于它。

　　C#的finalizer语法最有可能引起转向C#的C++程序员的混淆。请看见下列C#代码：

class R { ~R(){} }

　　好，这样~R看起来象一个析构器但实际是个finalizer。为什么？请与下面的C++代码比较：

ref class R { ~R(){ } !R(){ } };

　　这里~R是析构器（实际上等价于一个析构器的Dispose模式-但对C++人员来说，这它的行为象个析构器）而新的!R语法是为finalizer建立的-这样就不再有混淆而且语法看上去也与本机C++相匹配。

　　请看一下C#泛型语法：

class R<T>{};

　　再请看一下C++的语法：

generic<typename T> ref class R{};

　　曾经使用过模板的人马上就看出这种C++语法，而C#语法不能保证其没有混淆性且也不直观。我的观点是，如果你以前具有C++背景，C++/CLI语法将最贴近于你以前所用。C#(以及J#)看上去象C++，但是还有相当多的极为使人烦火的奇怪语义差别而且如果你没有完全放弃C++，语法差别将永远不停地带给你混乱和挫折。从这种意义上说，我认为VB.NET更好些，至少它有自己唯一的语法，所以那些共用C++和VB.NET的人不会产生语法混乱。

　　8. 结论

　　最后，至于你用什么语言编程，这可能依赖许多因素——如：你在学校学习的是什么语言，你是用什么语言开发的现有代码仓库，是否你的客户对你有具体的语言要求等。本文的主要目的是帮助你确定使用C++/CLI的几个明确的场所--这里，它比另外CLI语言更具有明显优势。如果你开发的应用程序有90%的使用时间是涉及本机interop，为何还要考虑使用另外的而不是C++？如果你想开发一个通用集合，为什么仅把你自己限制在泛型上，而不是结合泛型和模板的优势呢？如果你已经用C++工作，为什么还要学习一种新的语言?我常觉得象C#和VB.NET这样的语言总是尽量向开发者隐藏CLR，而C++不仅让你品味CLR，甚至可以让你去亲吻CLR! 

delete h;

((IDisposable)h).Dispose();

int c = *hi;

int i = (int) h;

ref struct ReferenceType {};

value struct ValueType {};

int v = h.Prop;

int v = h.Prop;

The second option for interop is to use P/Invoke. This is accomplished using the DllImport attribute, specifying the attribute on the method declaration for the function you want to import. Marshaling is handled according to how it has been specified in the declaration. However, DllImport is only useful if you have code that exposes the required functions through a DLL export.

When you need to call managed code from native code, CLR hosting is an option. In such a scenario, the native application has to drive all of the execution: setting up the host, binding to the runtime, starting the host, retrieving the appropriate AppDomain, setting up the invocation context, locating the desired assembly and class, and invoking the operation on the desired class. This is definitely one of the most robust solutions in terms of control over what and when things happen, but it is also incredibly tedious and requires a lot of custom code.

The fourth option, and quite possibly the easiest and the most performant, is to use the interop capabilities in C++. By throwing the /clr switch, the compiler generates MSIL instead of native machine code. The only code that is generated as native machine code is code that just can't be compiled to MSIL, including functions with inline asm blocks and operations that use CPU-specific intrinsics such as Streaming SIMD Extensions (SSE). The /clr switch is how the Quake II port to .NET was accomplished. The Vertigo software team spent a day porting the original C code for the game to code that successfully compiled as C++ and then threw the /clr switch. In no time they were up and running on the .NET Framework. Without adding any additional binaries and simply by including the appropriate header files, managed C++ and native C++ can call each other without any additional work on the part of the developer. The compiler handles the creation of the appropriate thunks to go back and forth between the two worlds.

代码生成

输出文件

调试

预处理器

语言

链接

预编译头

杂项

请参见

C/C++ 生成参考 | 编译器选项 | 设置编译器选项

Wow, its turning into a busy month. I just haven’t had any time to blog despite having a number of interesting topics to cover. I’ll try to get a few of them written soon. Here’s a topic from one of my regular readers.

The CLR naturally supports mixing managed and native method calls allowing you to easily call native functions from managed functions (which are of course natively compiled before execution) and visa versa. This is all largely transparent in C++. What’s not as transparent is how to mix managed and native types. The reason is that there is a greater distinction between native and managed types compared with function calls. Beside obvious differences such as those introduced by different calling conventions and virtual invocation, function calls aren’t all that different. Types however require a bit more help from the programmer/compiler since native and managed types can have very different characteristics. This is very evident in C# as you often need to decorate native type definitions with all kinds of attributes to control memory layout and marshalling. Fortunately for the C++ programmer the compiler takes care of much of this when you define or include native type definitions such as those found in the various Windows header files, but the programmer is still responsible for telling the compiler just how those types are to be used.

Visual C++ provides many of the building blocks for mixing native and managed types but in some cases you need to write a little code to help it along. Fortunately C++/CLI is very capable. Let’s consider a few different scenarios.

Embed Simple Managed Type in Native Type

Since the CLR needs to keep track of every single instance of a managed type in a process, storing some kind of reference/pointer/handle to a managed object in a native type is not directly supported since instances of native types can be allocated in any region of memory and cast to all kinds of foreign data types that would be completely opaque to the CLR and its services. Instead you need to register such occurrences with the CLR so that it is aware of these “native” references to managed types. This is achieved with the use of the GCHandle type. Internally GCHandle manages a static table of (native) pointers that are used to lookup the objects in the managed heap. Of course using GCHandle directly from C++ can be quite tedious. It’s a CLS compliant value type which means native pointers are represented by IntPtr values. It also does not preserve static type information so static_casts are inevitable. Fortunately Visual C++ ships with the gcroot native template class that provides a strongly-typed interface over the GCHandle type.

#include <vcclr.h>
 
ref struct ManagedType
{
    void HelloDotNet()
    {
        Console::WriteLine("Hello .NET");
    }
};
 
struct NativeType
{
    ManagedType m1;          // Error!
   
    ManagedType^ m2;         // Error!
   
    gcroot<ManagedType^> m3; // OK
};
 
void main()
{
    NativeType native;
    native.m3 = gcnew ManagedType;
 
    native.m3->HelloDotNet();
}

As you can see, gcroot provides a “smart” pointer for storing handles in native types. It may be smart but it does not provide automatic cleanup of resources. Specifically, the gcroot destructor makes no attempt to dispose of the managed object’s resources.

Embed Managed Resource in Native Type

Enter the auto_gcroot class. This native template class wraps a gcroot and provides transfer-of-ownership semantics for managed objects stored in native types. If you’re looking for a point of reference, think of the auto_ptr template class from the Standard C++ Library which does the same thing for native pointers. The auto_gcroot destructor takes care of “deleting” the handle which results in the object’s IDisposable::Dispose method (if any) being called.

#include <msclr\auto_gcroot.h>
 
ref struct ManagedType
{
    void HelloDotNet()
    {
        Console::WriteLine("Hello .NET");
    }
 
    ~ManagedType()
    {
        Console::WriteLine("dtor");

        // Compiler implements Dispose pattern...
    }
};
 
struct NativeType
{
    msclr::auto_gcroot<ManagedType^> m3; // OK
};
 
void main()
{
    NativeType native;
    native.m3 = gcnew ManagedType;
 
    native.m3->HelloDotNet();
}

The NativeType destructor (provided by the compiler) will automatically call the auto_gcroot destructor which will delete the managed object resulting in its destructor being called through its compiler generated Dispose method.

Embed Native Type in Managed Type

Now let’s turn things around. Let’s say we want to store a native type as a member of a managed type. The challenge is that the only native type the CLR really supports within managed types is a native pointer. C# programmers use IntPtr but that is only because IntPtr is the CLS compliant way of representing a native pointer and C# tries really hard to remain CLS compliant. The CLR fully supports storing native pointers without losing type information.

struct NativeType
{
};
 
ref struct ManagedType
{
    NativeType n1; // Error!

    NativeType* n2; // OK
};

That’s great except that now we have a resource management issue. Recall that C++ does not have the separation of memory and resource management evident in the CLR. The native object pointed to by the ManagedType member needs to be deleted. Here is one solution.

ref struct ManagedType
{
    NativeType* n2; // OK
 
    ~ManagedType()
    {
        if (0 != n2)
        {
            delete n2;
            n2 = 0;
        }
    }
};

Now the ManagedType has a Dispose implementation that will faithfully delete the native object. But this can become tedious and error prone very quickly. A better solution is to use some kind of “automatic” approach. Fortunately C++/CLI support by-value semantics for members so all we need is a managed auto-pointer template class. With such a class the ManagedType becomes really simple.

ref struct ManagedType
{
    AutoPtr<NativeType> n2; // OK
};

ManagedType stores a pointer to a native object and its destructor automatically deletes the object. Woohoo!

The C++ compiler really takes care of a lot of boilerplate code. If you’re not sure just how much code the compiler is taking care of for you then take a look at the compiled assembly in a disassembler.

Although Visual C++ does not provide a managed AutoPtr class, it is reasonably simple to write one. Here is a basic implementation.

template <typename T>
ref struct AutoPtr
{
    AutoPtr() : m_ptr(0)
    {
        // Do nothing
    }
    AutoPtr(T* ptr) : m_ptr(ptr)
    {
        // Do nothing
    }
    AutoPtr(AutoPtr<T>% right) : m_ptr(right.Release())
    {
        // Do nothing
    }
    ~AutoPtr()
    {
        if (0 != m_ptr)
        {
            delete m_ptr;
            m_ptr = 0;
        }
    }
    T& operator*()
    {
        return *m_ptr;
    }
    T* operator->()
    {
        return m_ptr;
    }
    T* Get()
    {
        return m_ptr;
    }
    T* Release()
    {
        T* released = m_ptr;
        m_ptr = 0;
        return released;
    }
    void Reset()
    {
        Reset(0);
    }
    void Reset(T* ptr)
    {
        if (0 != m_ptr)
        {
            delete m_ptr;
        }
        m_ptr = ptr;
    }
private:
    T* m_ptr;
};

In a future post I may provide a few realistic examples of mixing native and managed code, but I hope this introduction has given you a few ideas on how to mix native and managed code and types effectively in C++.


来自: http://weblogs.asp.net/kennykerr/archive/2005/07/12/Mixing-Native-and-Managed-Types-in-C_2B002B00_.aspx

When Microsoft brought out the Managed Extensions to C++ with VS.NET 7, C++ programmers accepted it with mixed reactions. While most people were happy that they could continue using C++, nearly everyone was unhappy with the ugly and twisted syntax offered by Managed C++. Microsoft obviously took the feedback it got very seriously and they decided that the MC++ syntax wasn't going to be much of a success.

On October 6th 2003, the ECMA announced the creation of a new task group to oversee development of a standard set of language extensions to create a binding between the ISO standard C++ programming language and Common Language Infrastructure (CLI). It was also made known that this new set of language extensions will be known as the C++/CLI standard, which will be supported by the VC++ compiler starting with the Whidbey release (VS.NET 2005).

Problems with the old syntax

• Ugly and twisted syntax and grammar - All those double underscores weren't exactly pleasing to the eye.
• Second class CLI support - Compared to C# and VB.NET, MC++ used contorted workarounds to provide CLI support, for e.g. it didn't have a for-each construct to enumerate .NET collections.
• Poor integration of C++ and .NET - You couldn’t use C++ features like templates on CLI types and you couldn’t use CLI features like garbage collection on C++ types.
• Confusing pointer usage - Both unmanaged C++ pointers and managed reference pointers used the same * based syntax which was quite confusing because __gc pointers were totally different in nature and behavior from unmanaged pointers.
• The MC++ compiler could not produce verifiable code

What C++/CLI gives us?

• Elegant syntax and grammar -This gave a natural feel for C++ developers writing managed code and allowed a smooth transition from unmanaged coding to managed coding. All those ugly double underscores are gone now.
• First class CLI support - CLI features like properties, garbage collection and generics are supported directly. And what's more, C++/CLI allows jus to use these features on native unmanaged classes too.
• First class C++ support - C++ features like templates and deterministic destructors work on both managed and unmanaged classes. In fact C++/CLI is the only .NET language where you can *seemingly* declare a .NET type on the stack or on the native C++ heap.
• Bridges the gap between .NET and C++ - C++ programmers won't feel like a fish out of water when they attack the BCL
• The executable generated by the C++/CLI compiler is now fully verifiable.

Hello World

				using
				namespace System;

void _tmain()
{
    Console::WriteLine("Hello World");
}

Well, that doesn't look a lot different from old syntax, except that now you don't need to add a reference to mscorlib.dll because the Whidbey compiler implicitly references it whenever you compile with /clr (which now defaults to /clr:newSyntax).

Handles

One major confusion in the old syntax was that we used the * punctuator with unmanaged pointers and with managed references. In C++/CLI Microsoft introduces the concept of handles.

				void _tmain()
{
    //The ^ punctuator represents a handle
    String^ str = "Hello World";
    Console::WriteLine(str);
}

The ^ punctuator (pronounced as cap) represents a handle to a managed object. According to the CLI specification a handle is a managed object reference. Handles are the new-syntax equivalent of __gc pointers in the MC++ syntax. Handles are not to be confused with pointers and are totally different in nature from pointers.

How handles differ from pointers?

• Pointers are denoted using the * punctuator while handles are denoted using the ^ punctuator.
• Handles are managed references to objects on the managed heap, pointers just point to a memory address.
• Pointers are stable and GC cycles do not affect them, handles might keep pointing to different memory locations based on GC and memory compactions.
• For pointers, the programmer must deleteexplicitly or else suffer a leak. For handles delete is optional.
• Handles are type-safe while pointers are most definitely not. You cannot cast a handle to a void^.
• Just as a new returns a pointer, a gcnew returns a handle.

Instantiating CLR objects

				void _tmain()
{
    String^ str = gcnew String("Hello World");
    Object^ o1 = gcnew Object();
    Console::WriteLine(str);
}

The gcnew keyword is used to instantiate CLR objects and it returns a handle to the object on the CLR heap. The good thing about gcnew is that it allows us to easily differentiate between managed and unmanaged instantiations.

Basically, the gcnew keyword and the ^ operator offer just about everything you need to access the BCL. But obviously you'd need to create and declare your own managed classes and interfaces.

Declaring types

CLR types are prefixed with an adjective that describes what sort of type it is. The following are examples of type declarations in C++/CLI :-

• CLR types
  • Reference types
    • refclass RefClass{...};
    • refstruct RefClass{...};
  • Value types
    • value class ValClass{...};
    • value struct ValClass{...};
  • Interfaces
    • interfaceclass IType{...};
    • interfacestruct IType{...};
  • Enumerations
    • enumclass Color{...};
    • enumstruct Color{...};
• Native types
  • class Native{...};
  • struct Native{...};

				using
				namespace System;

interfaceclass IDog
{
    void Bark();
};

refclass Dog : IDog
{
public:
    void Bark()
    {
        Console::WriteLine("Bow wow wow");
    }
};

void _tmain()
{
    Dog^ d = gcnew Dog();
    d->Bark();
}

There, the syntax is now so much more neater to look at than the old-syntax where the above code would have been strewn with double-underscored
 keywords like __gc and __interface.

Boxing/Unboxing

Boxing is implicit (yaay!) and type-safe. A bit-wise copy is performed and an Object is created on the CLR heap. Unboxing is explicit - just do a reinterpret_cast and then dereference.

				void _tmain()
{
    int z = 44;
    Object^ o = z; //implicit boxingint y = *reinterpret_cast<int^>(o); //unboxing

    Console::WriteLine("{0} {1} {2}",o,z,y);

    z = 66; 
    Console::WriteLine("{0} {1} {2}",o,z,y);
}

// Output// 44 44 44// 44 66 44

The Objecto is a boxed copy and does not actually refer the int value-type which is obvious from the output of the second Console::WriteLine.

When you box a value-type, the returned object remembers the original value type.

				void _tmain()
{
    int z = 44;
    float f = 33.567;

    Object^ o1 = z; 
    Object^ o2 = f; 

    Console::WriteLine(o1->GetType());
    Console::WriteLine(o2->GetType());    
}

// Output// System.Int32// System.Single

Thus you cannot try and unbox to a different type.

				void _tmain()
{
    int z = 44;
    float f = 33.567;

    Object^ o1 = z; 
    Object^ o2 = f;

    int y = *reinterpret_cast<int^>(o2);//System.InvalidCastExceptionfloat g = *reinterpret_cast<float^>(o1);
//System.InvalidCastException
}

If you do attempt to do so, you'll get a System.InvalidCastException. Talk about perfect type-safety! If you look at the IL generated, you'll see the MSIL box instruction in action. For example :-

				void Box2()
{
    float y=45;
    Object^ o1 = y;
}

gets compiled to :-

.maxstack  1
.locals (float32 V_0, object V_1)

  ldnull
  stloc.1ldc.r4     45.
  stloc.0ldloc.0
  box   [mscorlib]System.Single
  stloc.1ret

According to the MSIL docs, "The box instruction converts the ‘raw’ valueType (an unboxed value type) into an instance of type Object (of type O). This is accomplished by creating a new object and copying the data from valueType into the newly allocated object."

Further reading

• Write Faster Code with the Modern Language Features of Visual C++ 2005 [from MSDN]
• To C++ or not to C++, that is the question! [from my blog]

Conclusion

Alright, so why would anyone want to use C++/CLI when they can use C#, J# and that VB thingie for writing .NET code? Here are the four reasons I gave during my talk at DevCon 2003 in Trivandrum (Dec 2003).

• Compile existing C++ code to IL (/clr magic)
• Deterministic destruction
• Native interop support that outmatches anything other CLI languages can offer
• All those underscores in MC++ are gone ;-)

About Nishant Sivakumar

Editor Site Builder

Nish is a real nice guy living in Toronto who has been coding since 1990, when he was 13 years old. Originally from sunny Trivandrum in India, he has moved to Toronto so he can enjoy the cold winter and get to play in some snow. He works for The Code Project and handles the Dundas MFC products Ultimate Toolbox, Ultimate Grid and Ultimate TCP/IP that are sold exclusively through The Code Project Storefront. He frequents the CP discussion forums when he is not coding, reading or writing. Nish hopes to visit at least three dozen countries before his human biological mechanism stops working (euphemism used to avoid the use of the d-word here), and regrets that he hasn't ever seen snow until now (will be rectified this December). Oh btw, it must be mentioned that normally Nish is not inclined to speak about himself in the 3rd person. Nish has been a Microsoft Visual C++ MVP since October, 2002 - awfully nice of Microsoft, he thinks. He maintains an MVP tips and tricks web site - www.voidnish.com where you can find a consolidated list of his articles, writings and ideas on VC++, MFC, .NET and C++/CLI. Oh, and you might want to check out his blog on C++/CLI, MFC, .NET and a lot of other stuff - blog.voidnish.com Nish loves reading Science Fiction, P G Wodehouse and Agatha Christie, and also fancies himself to be a decent writer of sorts. He has authored a romantic comedy Summer Love and Some more Cricket as well as a programming book – Extending MFC applications with the .NET Framework. Click here to view Nishant Sivakumar's online profile.

C++的管理扩展

简介

C++管理扩展是一组语言扩展，它帮助Microsoft Visual C++开发人员为微软.NET编写应用程序。

管理扩展是有用的，如果你：

• 希望提高开发人员使用C++编写.NET应用程序的生产率
• 要分阶段地将一大段代码从非管理C++中移植到.NET平台上
• 想从.NET Framework应用程序中使用已有的非管理C++组件。
• 想从非管理C++中使用.NET Framework组件
• 在同一应用程序中混合非管理C++代码和.NET代码

C++管理扩展为开发人员定位.NET Framework提供了无比的灵活性。传统的非管理C++和管理C++代码可以自由地混合在一个
应用程序中。用管理扩展编写的应用程序可以利用两种代码的优点。使用管理扩展，现有组件可以方便地封装到.NET组件中，
在与.NET集成的同时保留原有投资。

什么是管理扩展?
扩展允许你在C++中编写在.NET Framework控制下运行的管理（或.NET）类。（非管理C++类运行在传统的微软基于Windows?
的环境中。）一个管理类是一个内置的.NET类，可以完全利用.NET Framework。

管理扩展是Visual C++开发系统的新关键字和属性。它们允许开发人员决定哪些类或函数编译为管理或非管理代码。
这些部分然后就可以平滑地与其它部分或外部库交互。

管理扩展也用于在C++源代码中表示.NET类型和概念。这就允许开发人员容易地编写.NET应用程序，而无需编写额外代码。

主要使用环境

• 将现有代码平滑地移植到 .NET
  如果你在C++代码上有大量投资，管理扩展将帮你将它们平滑地转移到.NET平台中。因为你可以在一个应用程序--
• 甚至是同一文件中混合管理和非管理代码，你可以用很长时间转移代码，一个组件接一个组件地转换到.NET中。
• 或你可以继续在非管理C++中编写组件，以利用该语言的强大功能和灵活性，只用管理扩展编写少量的高性能的
• 封装器（它使你的代码可以从.NET组件中调用）。
• 从 .NET语言中访问C++组件
  管理扩展允许你从任何.NET语言中调用C++类。你需要用扩展编写简单的封装器，它将你的C++类和方法暴露为
• 管理类。封装器是完全的管理类，可以从任何.NET语言中调用。封装器类是作为了管理类与非管理C++类间的
• 映射层。它简单地将方法调用直接传递到非管理类中。管理扩展可用于调用任何内置的动态链接库（DLL）及
• 内置类。
• 从内置代码中访问.NET 类
  使用管理扩展，你可以创建并从C++代码中直接调用.NET类。你可以编写将.NET组件当作任何其它管理C++类的
• C++代码。你可以使用.NET Framework中内置的COM调用.NET类。你使用COM还是使用管理扩展访问.NET组件
• 要依赖于你的工程。在一些情况下，利用现有的COM支持是最好的选择。在另一些情况下，使用管理扩展可能
• 会增加性能和开发者的生产率。
• 在同一可执行文件中的管理和内置代码
  Visual C++编译器能在管理和非管理上下文中自动而透明的翻译数据、指针和指令流。这个过程是允许管理扩展
• 无缝地与非管理代码交互的过程。开发人员能够控制什么样的数据和代码可以管理。选择每个类或函数是管理
• 还是非管理的能力为开发人员提供了更大的灵活性。一些代码或数据类型在非管理环境中执行得要比较好。
• 另一方面，管理代码由于如碎片收集和类库等特性，它提高了开发人员的生产率。现有非管理代码可以一次
• 一部分地转化为管理代码，因此保留了已有的投资。

为了使得现存的非.NET代码都可用，微软的设计使得CLR可以在应用程序里同时包含托管和非托管代码。CLR支持三种互操作：

托管代码调用DLL（就是我们说的动态链接库）中的非托管函数

托管代码使用现存的COM组建（非托管组建作为COM服务器）

非托管代码使用托管类型（托管类型作为COM服务器）

互操作性
是否可以在 .NET 框架程序中使用 COM 对象？
是。您现在部署的任何 COM 组件都可以在托管代码中使用。通常情况下，所需的调整是完全自动进行的。

特别是，可以使用运行时可调用包装 (RCW) 从 .NET 框架访问 COM 组件。此包装将 COM 组件提供的 COM 接口转换为与 .NET 框架兼容的接口。对于 OLE 自动化接口，RCW 可以从类型库中自动生成；对于非 OLE 自动化接口，开发人员可以编写自定义 RCW，手动将 COM 接口提供的类型映射为与 .NET 框架兼容的类型。

是否可以在 COM 程序中使用 .NET 框架组件？
是。您现在创建的托管类型都可以通过 COM 访问。通常情况下，所需的配置是完全自动进行的。托管开发环境的某些新特性不能在 COM 中访问。例如，不能在 COM 中使用静态方法和参数化构造函数。一般，提前确定给定类型所针对的用户是一种较好的办法。如果类型需要在 COM 中使用，您将被限制在使用 COM 可访问的特性。

默认情况下，托管类型可能是可见的，也可能是不可见的，这由用于编写托管类型的语言决定。

特别是，可以使用 COM 可调用包装 (CCW) 从 COM 访问 .NET 框架组件。这与 RCW（请参阅上一个问题）相似，但它们的方向相反。同样，如果 .NET 框架开发工具不能自动生成包装，或者如果自动方式不是您所需要的，则可以开发自定义的 CCW。

 是否可以在 .NET 框架程序中使用 Win32 API？
是。使用 P/Invoke，.NET 框架程序可以通过静态 DLL 入口点的方式来访问本机代码库。

下面是 C# 调用 Win32 MessageBox 函数的示例：

using System;
using System.Runtime.InteropServices;

class MainApp
{
    [DllImport("user32.dll", EntryPoint="MessageBox")]
    public static extern int MessageBox(int hWnd, String strMessage, String strCaption, uint uiType);

    public static void Main()
    {
        MessageBox( 0, "您好，这是 PInvoke！", ".NET", 0 );
    }
}

-----------------------------------------------------------------------------
什么是托管代码和托管数据？

托管代码是为面向公共语言运行库的服务编写的代码（请参阅“什么是公共语言运行库？”）。为了面向这些服务，该代码必须向运行库提供最低级别的信息（元数据）。默认情况下，所有 C#、Visual Basic .NET 和 JScript .NET 代码都受托管。默认情况下，Visual Studio .NET C++ 代码不受托管，但编译器可以通过指定命令行开关 (/CLR) 来产生托管代码。
与托管代码密切相关的是托管数据（由公共语言运行库的垃圾回收器分配和释放的数据）。默认情况下，C#、Visual Basic 和 JScript .NET 数据受托管。然而，通过使用特殊的关键字可以将 C# 数据标记为非托管。默认情况下，Visual Studio .NET C++ 数据不受托管（即使在使用 /CLR 开关时），但在使用 C++ 托管扩展时，可以通过使用 __gc 关键字将类标记为托管。正如名称所暗示的，这意味着用于类实例的内存受垃圾回收器的托管。另外，类成为 .NET 框架社区的一名完全参与的成员，这既带来了好处，也带来了限制。其中一个好处是与用其他语言编写的类的正确互操作性（例如，托管 C++ 类可以从 Visual Basic 类继承）。其中一个限制是托管类只能从基类继承。

--------------------------------------------------------------------------------
什么是公共语言运行时 (CLR)？
公共语言运行时是 .NET 框架应用程序的执行引擎。

它提供许多服务，包括：

代码管理（加载和执行）

应用程序内存隔离

类型安全验证

IL 到本机代码的转换

元数据（增强的类型信息）访问

为托管对象管理内存

强制代码访问安全

异常处理，包括跨语言异常

托管代码、COM 对象和现有 DLL（非托管代码和数据）之间的互操作

自动进行对象布局

对开发人员服务（配置、调试等）的支持

什么是公共类型系统 (CTS)？
公共类型系统是多信息类型系统，它被内置在公共语言运行时中，支持大多数编程语言中的类型和操作。公共类型系统支持大量编程语言的完全实现。

什么是公共语言规范 (CLS)？
公共语言规范是一组结构和限制，用作库编写者和编译器编写者的指南。它使任何支持 CLS 的语言都可以完全使用库，并且使这些语言可以相互集成。公共语言规范是公共类型系统的子集。对于那些需要编写代码供其他开发人员使用的应用程序开发人员，公共语言规范也非常重要。如果开发人员遵循 CLS 规则来设计公共访问的 API，那么就可以在支持公共语言运行时的任何其他编程语言中很容易地使用这些 API。

什么是 Microsoft 中间语言 (MSIL)？
MSIL 是与 CPU 无关的指令集。.NET 框架程序被编译成 MSIL。它包含加载、存储、初始化和调用对象方法的指令。

与元数据和公共类型系统结合，MSIL 允许真正的跨语言集成。

MSIL 在执行前被转换为机器代码，而不是一边解释一边执行。