C#抽象工厂模式的几种实现方法及比较

转载地址：http://www.cndw.com/tech/net/2006042758468.asp 　　利用设计模式可以使我们的代码更灵活，更容易扩展，更容易维护。各种面向对象的程序设计语言都提供了基本相同的机制：比如类、继承、派生、多态等等。但是又有各自的特色，C# 中的反射机制便是一个很重要的工具，好好地利用就可以在实际中发挥很大的作用。 　　我们来看一个例子： 我的程序中有需要一系列的对象，比如apple,orange…, 要想利用他们，我们就必须在程序中根据用户要求，然后一个个调用 new 操作符来生成他们，这样客户程序就要知道相应的类的信息，生成的代码显然不够灵活。我们可以在代码中不利用具体的类，而只是说明我们需要什么，然后就能够 得到我们想要的对象吗？ 　　哦，我们都看设计模式，听吧，很多人都在那里鼓吹他们是如何如何的棒，我们看看怎么样利用他们来解决问题。目 标明确了，那我们看看哪个能够符合我们的要求。GoF的《设计模式》都看过吧，似懂非懂的看了一些，那我们看看能够不能够“凑”上去呢？J 嗯，我们的程序考虑的是对象怎么创建的，创建型模式应该符合要求吧。然后我们浏览一下各模式的“意图”部分。呵呵，第一个好像就撞到彩了，抽象工厂，我们 看看吧，“提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类”，至少“无需指定它们具体的类”符合我们的要求。来看看它的结构吧： 我们的问题好像用不到这么复杂吧，只有orange,apple等等（应该就是product了），他们显然是一类的，都是fruit,我们只要一个生 产水果的工厂就可以，左边的继承层次不要，只有一个FruitFactroy看看行不，先别管它正统不正统，实用就行J 　　下面的一些东西显然是我们需要的： Public interface IFruit { } public class Orange:IFruit { 　public Orange() 　{ 　　Console.WriteLine("An orange is got!"); 　} } public class Apple:IFruit { 　public Apple() 　{ 　　Console.WriteLine("An apple is got!"); 　} } 　　我们的FruitFactory应该是怎么样呢？上面的结构图中它给的是CreateProductA,那好，我就MakeOrange，还有一个CreateProductB,俺MakeOrange还不行？？ public class FruitFactory { 　public Orange MakeOrange() 　{ 　　return new Orange(); 　} 　public Apple MakeApple() 　{ 　　return new Apple(); 　} } 　　怎么使用这个工厂呢？我们来写下面的代码： string FruitName = Console.ReadLine(); IFruit MyFruit = null; FruitFactory MyFruitFactory = new FruitFactory(); switch (FruitName) { 　case "Orange": 　　MyFruit = MyFruitFactory.MakeOrange(); 　　break; 　case "Apple": 　　MyFruit = MyFruitFactory.MakeApple(); 　　break; 　default: 　　break; } 　　编译运行，然后在控制台输入想要的东西，呵呵，成功了。沉浸在幸福中的你得意忘形了吧。

发布日期： 六, 18 八月 2007 06:02:01 GMT
计算机与 Internet |
阅读完整项

简单工厂模式与工厂方法模式 (ZZ)

发布日期： 五, 17 八月 2007 09:39:37 GMT
计算机与 Internet |
阅读完整项

简话设计模式 (ZZ)

发布日期： 一, 13 八月 2007 14:15:10 GMT
计算机与 Internet |
阅读完整项

C++/CLI中实现singleton模式

C++/CLI中实现singleton模式

发布日期： 一, 13 八月 2007 05:35:44 GMT
计算机与 Internet |
阅读完整项

C++/CLI：第一流的CLI语言 (ZZ)

C++/CLI：第一流的CLI语言

　　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!

 
发布日期： 一, 13 八月 2007 05:30:18 GMT
计算机与 Internet |
阅读完整项

C++/CLI思辨录之传递托管堆地址 (ZZ)

发布日期： 一, 13 八月 2007 03:39:32 GMT
计算机与 Internet |
阅读完整项

托管代码中的指针 (ZZ)

 

int^ m_int = gcnew int(100);

interior_ptr<int> ipint = &*m_int; //ok

interior_ptr<int> ipint = m_int;   //error

Value class Vtest{}
Ref class Rtest{}

Vtest ^vtest = gcnew Vtest;        //值类型对象

pin_ptr< Vtest > pinp;
pinp = vtest;            //error
pinp = &* vtest;        //ok
interior_ptr< Vtest > ip;
ip = &* vtest;        //ok


pin_ptr< Vtest ^> pinhundle;
pinhundle = vtest;        //error
pinhundle = & vtest;        //ok
interior_ptr< Vtest ^> iphundle;
iphundle = & vtest;        //ok


RTest ^rtest = gcnew RTest;        //引用类型对象
pin_ptr< Rtest > pinp;             //error , 不可以钉住引用类型对象
interior_ptr < Rtest > pinp;    //error , 不可以指向引用类型对象


ref class G {
public:
   void incr(int* pi) { *pi += 1; }
};
ref struct H { int j; };
void f( G^ g ) {
   H ^ph = gcnew H;
   Console::WriteLine(ph->j);
   pin_ptr<int> pj = &ph->j;    //ok,可以钉住引用类型对象的成员
   g->incr(  pj );
   Console::WriteLine(ph->j);
}

value class Test 
{
public:
    int i; 
};

#pragma unmanaged
void incr (int *i)
{
    (*i) += 10;
}

#pragma managed
void main () 
{
    Test ^test = gcnew Test();
    interior_ptr<int> ip = &test->i;
    (*ip) = 5;
//  incr( ip );            // invalid 
    pin_ptr<int> i = ip;   // i is a pinned int pointer
    incr( i );             // pinned pointer to interior pointer passed to a
                           // native function call expecting a native pointer
    Console::WriteLine ( test->i );
}

    pin_ptr<ClassValue> pValue = &value;;
    ClassValue* p = pValue;            //ok

    interior_ptr<ClassValue> pValue = &value;;
    ClassValue* p = pValue;            //error

发布日期： 一, 13 八月 2007 02:21:40 GMT
计算机与 Internet |
阅读完整项

C++/CLI思辨录之再谈继承 (ZZ)

C++/CLI思辨录之再谈继承

发布日期： 五, 10 八月 2007 08:20:49 GMT
计算机与 Internet |
阅读完整项

C++/CLI思辨录之内部指针的两面性 (ZZ)

C++/CLI思辨录之内部指针的两面性

发布日期： 五, 10 八月 2007 07:51:18 GMT
计算机与 Internet |
阅读完整项

C++/CLI思辨录之代理构造函数 (ZZ)

C++/CLI思辨录之代理构造函数

发布日期： 五, 10 八月 2007 05:05:41 GMT
计算机与 Internet |
阅读完整项

C++/CLI思辨录之拷贝构造函数 (ZZ)

C++/CLI思辨录之拷贝构造函数

发布日期： 五, 10 八月 2007 03:55:02 GMT
计算机与 Internet |
阅读完整项

浅议C++/CLI的gcnew关键字 (ZZ)

发布日期： 五, 10 八月 2007 02:41:52 GMT
计算机与 Internet |
阅读完整项

C++/CLI思辨录之Object的对象布局 （ZZ）

C++/CLI思辨录之Object的对象布局

C++/CLI相对纯C++来说，支持创建托管引用对象，托管对象由虚拟机来分配内存和管理，程序员可以不再担心内存泄漏的问题。其实，说白了也就是相当于自己创建一个内存池，并且虚拟机实际上也是这样做的。

　　在CLI中，所有的类都从Object派生，包括int这样的值。那么Object的内部结构是怎么样的呢？通过对vm代码的研究，可以看到大致上的结构如下：

用户保存一个托管对象的句柄，其实可以看作是一个指向Object的指针，在Object里面包含一个MethodTable的指针，这个 MethodTable保存了类型的信息以及一些函数，这就好比虚函数指针一样。很多的操作都通过该指针来完成，比如Allocate(),比如Box (),UnBox()等等。紧跟在MethodTable后面的就是真实的数据了。

　　这个MethodTable是vm里面很核心的一个类，通过它可以完成很多的操作。

原文地址：http://dev.yesky.com/msdn/28/2048528.shtml

这篇文章似乎没有完

发布日期： 五, 10 八月 2007 02:18:11 GMT
计算机与 Internet |
阅读完整项

C++/CLI中栈对象的设计问题 (ZZ)

R r;
R h=gcnew R;

　　好像记得Herb Sutter曾经说过他们将来可能会在真正的方法栈中分配r ——说实话恐怕只有C++背景的人敢这么“胡思乱想”:) 他们现在只是想在语法层面让程序员"感觉"就像r是从栈中分配的一样。又一个syntax sugar:)

　　当然为了对称和语义的完美，有时候还需要在r上应用%——虽然背后仍是什么也没做:)

　　#2、C++/CLI编译器默认情况下不会自动产生拷贝构造函数和拷贝赋值操作符

　　这一点非常令人烦恼，几乎让人“望栈对象而却步”。更糟糕的是BCL中的所有类型都没有提供拷贝构造函数和拷贝赋值操作符——因为恐怕只有C++/CLI会用到他们。

　　话说回来，即使C++/CLI会自动产生拷贝构造函数和拷贝赋值操作符，那么继承自BCL的类型还是会很麻烦。

　　#3、如果函数要被其他CLI语言调用，那么就不能将其参数设计为栈对象

a. static void add(R r){...}

　　编译出来有一个modopt元数据，所以可以被其他语言调用，但是如果被其他语言调用，比如C#，那么其他语言将是以传值的方式传递引用，而C++/CLI将是传递对象拷贝（要调用拷贝构造器），所以语义混乱，完全不可以这样做。

b. static void add(R% r){...}

　　由于编译出来都有一个modreq元数据，所以不能被其他CLI语言调用。

　　#4、如果函数要被其他CLI语言调用，那么也不能将其返回值设计为栈对象

a. static R add(){...}

b. static R% add(){...}

　　两者编译出来都有一个modreq元数据，所以都不能被其他CLI语言调用。

　　#5。使用BCL时，如果要传递栈对象，总要使用“莫名其妙”的%操作符

　　比如：

String s("abc");
ArrayList list;
list.Add(%s);

　　实在很不好，还是使用追踪引用比较好：

String^ s="abc";
ArrayList^ list=gcnew ArrayList();
list->Add(s);

　　总结一下：

　　#1和#5对栈对象的可用性影响不算大，毕竟从语义层面来理解，还是行得通的。

　　但是，#2、#3、#4的影响就很大。#3和#4使得我们必须放弃使用栈对象来进行互操作。而#2会让编写C++/CLI代码非常的不方便——除非你以后不想使用栈对象。

　　现在的问题是，是否C++/CLI中的栈对象只是为了获得自动确定性资源回收而存在？值得这样做吗？

原文地址：http://dev.yesky.com/msdn/29/2011029.shtml

发布日期： 四, 09 八月 2007 07:51:40 GMT
计算机与 Internet |
阅读完整项

C++/CLI基本数据类型探索 (ZZ)

发布日期： 四, 09 八月 2007 07:39:38 GMT
计算机与 Internet |
阅读完整项

CLI类型声明比较 (ZZ)(节选)

发布日期： 二, 07 八月 2007 08:37:32 GMT
计算机与 Internet |
阅读完整项

C++/CLI语言标准草案第8章语言概述节选翻译 (ZZ)

发布日期： 二, 07 八月 2007 08:20:36 GMT
计算机与 Internet |
阅读完整项

标准C++及C++/CLI发展综述 (ZZ)

发布日期： 二, 07 八月 2007 08:16:50 GMT
计算机与 Internet |
阅读完整项

从C++到C++/CLI (ZZ)

从C++到C++/CLI

看起来只是在C++后面多写了一个“/CLI”，然而其意义却远不止于此，google的c++.moderated版上为此还发起了数星期的讨论，在国内大部分人对C++/CLI还不是很了解的情况下，google上面已然硝烟四起...

就像我们作出其它任何选择一样，在选择之前最重要的是先要清楚为什么作出这样或那样的选择——C++/CLI到底提供了哪些优势？为什么我们（标准C++程序员）要选择C++/CLI而不是C#？我们能够得到什么？CLI平台会不会束缚C++的能力？

这 些都是来自标准C++社区的疑问。从google上面的讨论看来，更多来自标准C++社区的程序员担心的是C++/CLI会不会约束标准C++的能力，或 者改变标准C++发展的方向，也有一部分人对C++/CLI的能力持怀疑态度。另外一些人则是询问C++/CLI能够带来什么。

这些被提出的问题在google上面一一得到了答案。好消息是：情况比乐观的人所想象的或许还要更好一些——

世界改变了吗？

对 于谙于标准C++的程序员来说，最为关心的还是：在C++/CLI中，世界还是他们熟悉的那个世界吗？在标准C++的世界里，他们手里的各种魔棒——操作 符重载|模板|多继承（语言），STL|Boost|ACE（库）——还能挥舞出五彩缤纷的火焰吗？是不是标准C++到了.NET环境下就像被拔掉了牙的 老虎一样——Managed C++ Extension的阴影是不是还笼罩在他们的心头？

答案是：以前你所能做的，现在仍然能做，世界只是变得更广阔了——

什么是C++/CLI？

l         C++/CLI是一集标准化的语言扩展（对标准C++进行扩展），而并非另起炉灶的另一门新语言。所以C++/CLI是标准C++的一个超集。

l         C++/CLI是一门ECMA标准[1]（并且会被提交给ISO标准化委员会），而不是微软的专有语言。参与C++/CLI标准的修订的有很多组织（或公 司），其中包括Edison Design Group，Dinkumware公司等，微软在把C++/CLI标准草案提交给ECMA组织后就放弃了对其的控制权，而是将它作为一份公开发展的标准， 任何使用C++/CLI的用户都可以为它的发展提出自己的建议。

l         C++/CLI的目的是把C++带到CLI平台上，使C++能够在CLI平台上发挥最大的能力。而并非把C++约束在CLI平台(CLI本身也是ISO标 准化的)上。相反，原来标准C++的能力丝毫没有减弱，并且，通过C++/CLI中的标准扩展，C++具有了原来没有的动态编程能力以及一系列的 first class的.NET特性。这些扩展并非是专有的，而是以一种标准的方式呈现。

C++/CLI有什么优越性？

l         动态编程和refelection——标准C++是一门非常静态的语言，其原则是尽量在编译期对程序的合法性和逻辑作出检查。而在运行时的动态信息方面， 标准C++是有所欠缺的。例如，标准C++在运行期能够对动态对象进行查询的就只有typeid操作符，而typeid()返回的typeinfo类虽然 是个唯一标识，但是也仅仅止于“唯一”而已，首先标准C++并未规定typeinfo的底层二进制表示，所以用它作为跨平台的类唯一标识符就不可能了，其 次typeinfo类几乎仅仅就表示类名字而已，这种非常“薄”的运行时类型信息阻止了标准C++在分布式领域的能力（IDL就是为了弥补标准C++在运 行期类型信息的不足，但是IDL对于拥有元数据的语言如JAVA或C#根本就不是必须的，同时IDL也使C++在分布式领域的使用不那么简易）。由于标准 C++的Native特点，所以其代码一经编译便几乎丧失所有的类型信息，从而使得运行期无法对程序本身做几乎任何的改动，换句话说，标准C++的代码一 经编译就几乎变成了死的。而C++/CLI改变了这一现状，C++/CLI拥有完备的元数据，允许程序在运行期查询完整的类型信息，并可以由类型信息动态 创建对象，甚至可以动态创建类型，添加方法等等，这种强大的运行期的动态特性对于现代应用领域（例如分布式WEB应用）是必须的。

l         GC——现在谁也不会说“往C++中加入GC就是终结了C++”这种话了。就连Bjarne Stroustrup也同意如果C++要被用于大型或超大型的软件开发中去，最好要有一个良好的可选的GC支持。GC与否，已经不再是个值得争论的问题， 问题是，我们如何把它实现的更好——C++/CLI中的GC是目前最为强大的GC机制之一——分代垃圾收集。GC的好处是可以简化软件的开发模型，在效率 并非极其关键的领域，GC可以很大程度上提高生产率。C++/CLI中的GC很重要的一点是：它正是可选的。这一点不同于JAVA或C#，对于后者，GC 无处不在，对象只能分配在托管堆上。而在C++/CLI中，如果把你的对象分配在Native Heap上，你就得到和标准C++一样的高效内存管理。如果把对象分配在Managed Heap上，那么该对象的内存就由GC来自动回收。这种混合式的内存管理环境和C++/CLI的定位有关——毕竟，C++/CLI的定位是.NET平台上 的系统级编程语言，所以效率以及对底层的控制很重要，故保留了Native Heap。后面你会看到这种编程环境的优点。

l         BCL——.NET平台上的基础类库，BCL中丰富的类极大的方便了开发者。C++/CLI可以完全使用BCL中的任何类。

l         可移植性——毫无疑问，可移植性是个至关重要的问题，特别是对于标准C++社群的人们。C++/CLI对这个问题的答案是：“如果你的代码不依赖于本地二 进制库，就可以“一次编译，随处运行（在.NET平台上）”（使用“/clr:pure”编译选项将代码编译成可移植的纯MSIL代码）。如果你的代码某 部分依赖于本地的二进制库(如C输入输出流库)，那么这些部分仍然是源代码可移植的，而其它部分则可以“一次编译，随处运行”。对于标准C++来说，向来 保证的只是源代码的可移植性，所以我们并没有失去什么，相反，如果遵守协定——不用本地二进制库，例如，用BCL里的输入输出流库代替C输入输出流库—— 你就可以得到“一次编译，随处运行”的承诺，也就是说，你的代码经过编译（/clr:pure）后可以在其它任何.NET平台上运行——Unix， Linux下的Mono（移植到Unix，Linux下的.NET），以及FreeBSD，Mac OSX下的Rotor（.NET的开放源代码项目），等等。

习 惯了标准C++输入输出流的程序员可能要抱怨了——我们为什么要使用BCL里面的输出输出流？标准的iostream已经很好了！这里其实有一个解决方 案，使用 iostream的代码之所以不能“一次编译，随处运行”是因为代码要依赖于本地的二进制lib文件，而如果可以把iostream的实现重新也编译成纯 MSIL代码，那么使用它的代码编译后就完全可随处运行了。目前，这是个有待商榷的方案。不过，至少当面对“总得依赖于某些平台相关的二进制代码”这种情 况时，可以把平台相关的代码封装成DLL文件——对各个目标平台编译成不同的二进制版本，而程序的其它部分仍然只需一次编译即可，只要使用.NET的 P/Invoke就可以对不同平台调用相应的DLL了。

l         效率——作为.NET平台上的系统级编程语言，C++/CLI混合了Native和Managed两种环境。而不象C#那样只能进行托管编程。所以相对来 说，C++/CLI可以具有更高的效率——前提是你愿意把效率敏感的代码用极具效率的Native C++来写（当然，谁不愿意呢？）另外，因为标准C++是静态语言，所以作为标准C++的一个超集的C++/CLI能够在编译期得到更多的优化（静态语言 总是能够得到更多的优化，因为编译器能够知道更多的信息），从而具有更高的效率。相比之下，C#的编译期优化就弱了很多。

l         混合式的编程环境——这是C++/CLI独有的一种编程环境。你既可以进行高效的底层开发——对应于C++/CLI的标准C++子集，也可以在效率要求不 那么严格的地方使用托管式编程以提高生产率。然后把两者平滑的联结在一起，而这一切都在你熟悉的编程语言中完成，你使用你熟悉的编程习惯，熟悉的库，熟悉 的语言特性和风格… 不需要从头学习一门新的语言，不需要面对语言之间如何交互的问题。

l         习惯——谁也不能小觑习惯的力量。对于标准C++程序员，如果要在.NET平台上开发，C++/CLI是毫无疑问的首选语言，因为他们在标准C++中积累 起来的任何编程技巧，惯用法，以及对库的使用经验，代码的表达方式等等全都可以“移植”到C++/CLI中。C++/CLI保持对标准C++代码的完全兼 容，同时以最小最一致的语法扩展提供托管环境下编程的必要语义。

你需要改变什么？

      简单的答案是，几乎没有什么需要改变的。是的，你看到“几乎”两个字，总有些不安心:o)事实是：把现存的C++代码移植到C++/CLI环境下不用作任 何的改变——我曾经用Native C++写了一个程序，其中用到了STL，Boost里面的Lambda，MPL，Signal等库，然后我把编译选项“/clr”（甚至“/clr: pure”）打开，结果是程序完全通过了编译。而对于使用C++/CLI进行开发的程序员，则需要熟悉的就是.NET平台上的编程范式以及库的使用等，至 于以前你所熟悉的标准C++编程的各种编程手法，技巧，各种库的使用——Just Keep Them!

      所以，确切的说，你需要的是学习，而不是改变。

C++/CLI——优秀的混血儿

      C++/CLI最大的成功在于引入了混合式编程的环境，这是一种非常自由的环境，其中Native和Managed代码可以共存，可以相互沟通，从而完全接纳了标准C++的世界，同时也为另一个世界敞开了大门...

    下面就是C++/CLI扩展的几大关键特性——

Handle和gcnew——通往Managed世界的钥匙

       还记得在Managed C++ Extension世界里是如何访问托管类的吗？丑陋的__gc关键字无处不在——事实上，不仅是“丑陋”而已（MC++为什么会消亡？）。而在C++ /CLI里则引入了一个新的语法元素，名为Handle，写作“^”——你可以把它看成Managed世界里的Pointer（不过不能进行指针算术）。

Handle 用于持有Managed Heap上的对象，那么如何在Managed Heap上创建对象呢？原来的new显然不能用，那样会混淆其语义，所以C++/CLI引入了一个对应的gcnew关键字，这两个新的语法元素是操纵 Managed世界的关键。现在，使用Handle和gcnew，你就可以和任何托管类进行沟通。另外，既然有了Handle这个Managed指针，当 然，基于另外一些重要原因，Managed世界里也要有一个和Native引用类似的语法元素——这就是Managed引用“%”——“^”对应“*”， “%”对应“&”，这样一来，从语法的层面上，指针、引用、以及在堆上创建对象的语法就在两个世界里面对称一致了——哦，等等，还有解引用：对 Native Pointer解引用是以“*”，出于模板对形式统一性的要求，对Handle解引用也是用“*”。例如：

SomeManagedClass^ handle = gcnew SomeManagedClass( ... );

handle->someMethod();

SomeManagedClass% ref = *handle;

    那么，既然有gcnew，有没有gcdelete呢？答案是没有——虽然它们看起来很对称。理由是对于托管类，根本就不用回收内存。但更为重要的还是， delete的语义不仅仅是回收内存，从广义上说，delete是回收资源的意思，从这个意义上，delete托管类还是Native类的对象都是一个意 思。所以，即使你需要delete你的托管类对象，以强制其释放资源，你也应该用delete，这时候托管类的析构函数会被调用——是的，托管类也有析构 函数，它的语义和Dispose()一样，但是在C++/CLI里面，你不应该为你的托管类定义Dispose()函数，而总是应该用析构函数来代替它 （编译器会根据析构函数自动生成Dispose()函数），因为析构函数有一个最大的优点——

Deterministic Destruction & RAII —— 资源管理的利器

正 如每一个熟悉标准C++的程序员所清楚的：由C++构造及析构函数的语义保证所支持的RAII（“资源获取即初始化”[2]）技术是资源自动和安全管理的 利器，这里的资源可以包括内存，文件句柄，mutex，lock等。通过正确的使用RAII，管理资源的代码可以变得惊人的优雅和简单。相信有经验的C+ +程序员都熟悉应该类似下面的语句：

void f()

{

       ofstream outf(“out.txt”);

       out<<”...”;

       ...

} //outf在这里析构！

       这里，程序员根本不用手动清理outf，在函数结束（outf超出作用域）时，outf会自动析构，并释放其所有资源。即使后续的代码抛出了异常，C++ 语言也能保证析构函数会被调用。事实上，在异常抛出后，栈开解(stack unwind)的过程中，所有已经正确构造起来的局部对象都会被析构。这就为异常环境中资源的管理提供了一种强大而优雅的方式。

       而对于C#或Java，代码就没有这么优雅了（特别是java）——C#虽然有using关键字，但是代码仍然显得臃肿，而Java为了保证在异常情况下 资源能够正常释放，不得不用了丑陋冗长的try-finally块，在情况变得复杂化时，C#的和Java的代码都会变得越发臃肿。

       那么，在C++/CLI中，原来的那种优雅的，靠析构函数来确保资源正确释放的手段还存在吗？答案正如你所期望和熟悉的，RAII仍然可以使用，仍然和标准C++中的能力一样强大：

ref struct D

{

D(){System::Console::WriteLine(“in D::D()\n”);}

~D(){System::Console::WriteLine(“in D::~D()\n”);}

!D(){System::Console::WriteLine(“Finalized!\n”);}

};

int main()

{

       D d;  // in D::D()

       ...

} //d在这里析构！in D::~()

       ref关键字表示该类是Managed类。所有的ref类都继承自一个公共基类System::Object。至于struct和class的区别仍然和 标准C++中的一样。如你所见，对于ref类，你同样可以像在标准C++中那样定义析构函数，该析构函数会在确定的时候被调用——也就是D超出作用域时。 一切都与你以前的经验相符。

     值得注意的是，对于了解Java或C#的程序员，ref类的析构函数就是Dispose()，你不必也不应该另外手动定义一个Dispose()成员函 数。那么，Finalize函数到那里去了？既然ref类创建在托管堆上，那么迟早要被GC回收，这时候，应该被调用的Finalize函数在哪儿呢？C ++/CLI为此引入了一个新的语法符号“!D()”，这就是D的Finalize函数，这个“!D”函数被调用的时机是不确定的，要看GC什么时候决定 回收该类占用的空间。

       ~D()析构函数和标准C++里的用法完全相同，释放以前获取的资源。而对!D()的用法则和Finalize函数一样，由于其调用时机是不确定的，所以千万不要依赖于它来释放关键资源（如文件句柄，Lock等）。

       为ref类引入~D()和!D()极大的方便了资源管理，也符合了标准C++程序员所熟悉的方式。Herb Sutter[3]把这个能力看成C++/CLI在Managed环境下最为强大的能力之一。

pin_ptr —— 定身法

千 万不要小看了pin_ptr的能力，它是Native世界和Managed世界之间的桥梁。在通常情况下，任何时候，GC都会启动，一旦进行GC，托管堆 就会被压缩，对象的位置就会被移动，这时候所有指向对象的Handle都会被更新。但是，往往有时候程序员会希望能够把托管堆上的数据（的地址）传给 Native接口，比如，为了复用一个Native的高效算法，或者为了高效的做某些其它事情，这种情况下普通的Native指针显然不能胜任，因为如果 允许Native指针指向托管堆上的对象，那么一旦发生了GC，这些得不到更新的Native指针将指向错误的位置，造成严重的后果。办法是先把对象 “定”在Managed堆上，然后再把地址传给Native接口，这个“定身法”就是pin_ptr——它告诉GC：在压缩堆的时候请不要移动该对象！

array<char>^ arr = gcnew array<char>(3); //托管类

arr[0] = 'C';

arr[1] = '+';

arr[2] = '+';

pin_ptr<char> p = &arr[0];   // 整个arr都被定在堆上

char* pbegin=p;

std::sort(pbegin,pbegin+3); //复用Native的算法！

std::cout<<pbegin[0]<<pbegin[1]<<pbegin[2]; //输出 “++C”

       在上面的代码中，我们复用了STL里的sort算法。事实上，既然有了pin_ptr，我们可以复用绝大部分的Native算法。这就为我们构建一个紧凑高效的程序内核提供了途径。

       值得注意的是，一旦对象中的成员被定在了堆上，那么该对象整个就被定在了堆上——这很好理解，因为对象移动必然意味着其成员的移动。

       还有另一个值得注意的地方就是：pin_ptr只能指向某些特定的类型如基本类型，值类型等。因为这些类型的内存布局都是特定的，所以对于Native代 码来说，通过Native指针访问它们不会引起意外的后果。但是，ref class的内存布局是动态的，CLR可以对它的布局进行重整以做某些优化（如调整数据成员排布以更好的利用空间），从而不再是Native世界所能理解 的静态结构。然而，这里最主要的问题还是：ref class底层的对象模型和Native世界的对象模型根本就不一致（比如vtbl的结构和vptr的位置），所以用Native指针来接受一个ref class实例的地址并调用它的方法简直肯定是一种灾难。由于这个原因，编译器严格禁止pin_ptr指向ref class的实例。

interior_ptr —— 托管环境下的Native指针

    Handle的缺憾是不能进行指针运算（由于其固有的语义要求，毕竟Handle面对的是一个要求“安全”的托管环境），所以Handle的能力较为有 限，不如标准C++程序员所熟悉的Native指针那么强大。在STL中，iterator是一种极为强大也极具效率的工具，其底层实现往往用到 Native指针。而到了托管堆上，我们还有Native指针吗？当然，原来的形如T*的指针是不能再用了，因为它不能跟踪托管堆上对象的移动。所以C+ +/CLI中引入了一种新的指针形式——interior_ptr。interior_ptr和Native指针的语义几乎完全一样，只不过 interior_ptr指向托管堆，在GC时interior_ptr能够得到更新，除此之外，interior_ptr允许你进行指针运算，允许你解 引用，一切和Native指针并无二致。interior_ptr为你操纵托管堆上的数据序列（如array）提供了强大而高效的工具，iterator 模式因此可以原版照搬到托管环境中，例如：

template<typename T>

void sort2(interior_ptr<T> begin,interior_ptr<T> end)

{

    ... //排序算法

    for(interior_ptr<T> pn=begin;pn!=end;++pn)

    {

       System::Console::WriteLine(*pn);

    }

}

int main()

{

array<char>^ arr = gcnew array<char>(3);

    ... //赋值

    interior_ptr<char> begin = &arr[0]; //指向头部的指针

    interior_ptr<char> end = begin + 3;  //注意，不能写&arr[3]，会下标越界

    sort2(begin,end); //类似STL的排序方式！

}

T*，pin_ptr，interior_ptr——把它们放到一起

       T*，pin_ptr，interior_ptr是C++/CLI中三种最为重要的指针形式。它们之间的关系像这样：

       //很可惜，这里应该有一幅图的，可是原文显示不了，也没有搜到

强大的Override机制

        在标准C++中，虚函数重写机制是隐式的，只要两个函数的签名（Signature）一样，并且基类的同名函数为虚函数，那么不管派生类的函数是否为 virtual，都会发生虚函数重写。某种程度上，这就限制了用户对它的派生类的控制能力——虚函数的版本问题就是其一。而在C++/CLI中，你拥有最 为强大的override机制，你可以更为明显的来表示你的意图，例如下面的代码：

class B

{

public:

       virtual void f() ;

       virtual void g() abstract; //纯虚函数，需要派生类重写，否则派生类就是纯虚类

       virtual void h() sealed; //阻止派生类重写该函数

       virtual void i() ;

}

class D:public B

{

       virtual void f() new ; //新版本的f，虽然名字和B::f相同，但是并没有重写B::f。

       virtual void h() override ; //错误！sealed函数不能被重写

       virtual void k() = B::i ; //“命名式”重写！

}

       通过正确的使用这些强大的override机制，你可以获得对类成员函数更强大的描述能力，避免出乎意料的隐式重写和版本错误。不过需要提醒的是，“命名式”重写是一种强大的能力，但是需要谨慎使用，如果使用不当或滥用很可能导致名字错乱。

值类型&封箱和拆箱

       如果你来自C#，我几乎可以听到你的叹气声J 的确，在.NET平台上编程，你无可避免的要面对值类型和引用类型的微妙差别以及“疯狂”的隐式封箱——引用类型（对应于ref class）的实例是第一流的对象，继承自公共基类System::Object，拥有方法表，对象头等等。但是值类型（对应于value class）却极为简单，类似于C++中的POD[4]类型，没有方法表和对象头等，值类型应该被分配在栈上，而当你用Handle来持有值类型实例时， 它就会被隐式的封箱到托管堆上（因为Handle必须持有一个一流的对象），只有当值类型的实例被封箱到堆上的时候，它才会拥有第一流的对象特征，可以被 Object^来引用。

       这些都是.NET内在的特性，所有使用.NET平台的语言都必须遵守，从这个意义上说，.NET的确是最高统治者J

       幸运的是，情况或许没有你想象的那么糟糕，或许比在C#里面还要好一些——因为C++/CLI中的Handle的语法特征是如此明显，所以你几乎可以立即发现什么地方会出现封箱拆箱（尽管如此，还是要面对一些微妙的情况），我们来看一个例子：

value class V  //value关键字表示这是个值类型，值类型应该分配在栈上

{ int i;};

V v; //在栈上创建V的实例

//由于V^必须引用一个“完整”的对象，也就是具有方法表，元数据以及对象头并继承自System::Object公共基类的对象，所以v被隐式封箱到托管堆上。

V^ hv1 = v; //注意，隐式封箱！

V^ hv2 =%v; //也是封箱！把”%”用到值类型上会导致一个Handle，

                    //所以会封箱，这种形式比较明确！

hv1->i = 10; //改变的不过是堆上封箱后的对象中的i，v的成员i的值并未改变

v = *hv1; //unbox，然后逐位拷贝到栈上，这时候v.i为10

       这里你可能意识到了问题——既然用Handle来持有值类型总会导致它被封箱到托管堆上，那么万一我要写一个函数，接受一个（栈上的）值类型实例为实参并 改变其成员的值，该怎么办呢？如果使用Handle，那么你所指向的就不是原来的值而是封箱后的对象，从而看起来改变了其成员，其实只不过改变了一个“临 时”对象的值而已！所以，Handle在这里应该退居二线，这里是“%”(托管的引用，对应于Native引用——“&”)的用武之地——把一个 托管引用绑定到位于栈上的值类型不会引起封箱操作，我们看一个例子：

void adjust(V% ref_v)

{

       ref_v.i = 10; //改变ref_v的成员！

}

int main()

{

       V v;

       adjust(v); //不会引起封箱操作

       System::Console::WriteLine(v.i); //打印出10

}

       原则是：要修改栈上的值类型实例，优先使用“%”，而不是“^”。这样你将获得最好的效率和程序的正确性。

STL.NET

     STL是标准C++中最为优雅，使用最广泛的库之一，标准C++程序员在使用STL的过程中积累了大量的经验。当然，在C++/CLI的扩展世界里，人们 也期望能有这样的库，能够沿用他们熟悉以久的经验和技法，这就是STL.NET，为托管世界准备的STL！Stan Lippman[5]在MSDN上的一篇文展STL.NET Primer以简明扼要的方式阐述了STL.NET的优点[6]。

代码的组织

        虽然C++/CLI带来了强大的能力，但是对于从标准C++社群来的人们，则更愿意将他们的标准C++代码和使用了C++/CLI扩展特性的代码隔离开 来，以便让前者可以在不同平台上移植，而不是绑定到CLI平台。毕竟，用C++/CLI编程并不意味着你的所有代码都是和C++/CLI的扩展特性相关的 ——C++/CLI的定位是系统级编程，所以可以想象会有很大一部分人会非常愿意用标准C++来写效率关键的代码部分，例如你可以用标准C++来写高效的 算法，而这些算法应该可以被复用到其它Native环境中去。那么，如何把这些标准C++代码和C++/CLI的扩展特性隔离开来呢？如何隔离？不同编译 单元之间的界限就是最好的栅栏——把你的标准C++代码放在独立的头文件和源文件中，把使用了C++/CLI扩展的代码放在另外的头文件和源文件中。并 且，尽量不要在你的Native class中使用CLI的语法特性，如property，delegate，index等，尽量不要让你的Native Class继承自ref Class。总之，尽量保证代码结构的清晰，你将得到最大程度上的可移植性。

小结

        C++/CLI是一个创举，它把托管环境和Native环境整合在一起，使开发者同时拥有了“上天入地”的强大能力。显而易见，微软为了C++/CLI花 费了大量的心力。以使得标准C++程序员能够平滑的过渡到C++/CLI上面。所谓平滑，就是能够尽量保证原来的编程技巧，习惯，范式等，它的确做到了。 面对C++/CLI，已经不是争论该不该学习的问题，而是如何让它发挥更大的能量的问题。

原文地址：
http://blog.yesky.com/blog/cqfz/archive/2004/12/30/57339.html
发布日期： 二, 07 八月 2007 07:36:38 GMT
计算机与 Internet |
阅读完整项

什么是CLI (ZZ)