C#抽象工厂模式的几种实现方法及比较 | ||||
利用设计模式可以使我们的代码更灵活,更容易扩展,更容易维护。各种面向对象的程序设计语言都提供了基本相同的机制:比如类、继承、派生、多态等等。但是又有各自的特色,C# 中的反射机制便是一个很重要的工具,好好地利用就可以在实际中发挥很大的作用。
我们来看一个例子: 我的程序中有需要一系列的对象,比如apple,orange…, 要想利用他们,我们就必须在程序中根据用户要求,然后一个个调用 new 操作符来生成他们,这样客户程序就要知道相应的类的信息,生成的代码显然不够灵活。我们可以在代码中不利用具体的类,而只是说明我们需要什么,然后就能够 得到我们想要的对象吗? 哦,我们都看设计模式,听吧,很多人都在那里鼓吹他们是如何如何的棒,我们看看怎么样利用他们来解决问题。目 标明确了,那我们看看哪个能够符合我们的要求。GoF的《设计模式》都看过吧,似懂非懂的看了一些,那我们看看能够不能够“凑”上去呢?J 嗯,我们的程序考虑的是对象怎么创建的,创建型模式应该符合要求吧。然后我们浏览一下各模式的“意图”部分。呵呵,第一个好像就撞到彩了,抽象工厂,我们 看看吧,“提供一个创建一系列相关或相互依赖对象的接口,而无需指定它们具体的类”,至少“无需指定它们具体的类”符合我们的要求。来看看它的结构吧: 我们的问题好像用不到这么复杂吧,只有orange,apple等等(应该就是product了),他们显然是一类的,都是fruit,我们只要一个生 产水果的工厂就可以,左边的继承层次不要,只有一个FruitFactroy看看行不,先别管它正统不正统,实用就行J 下面的一些东西显然是我们需要的:
我们的FruitFactory应该是怎么样呢?上面的结构图中它给的是CreateProductA,那好,我就MakeOrange,还有一个CreateProductB,俺MakeOrange还不行??
怎么使用这个工厂呢?我们来写下面的代码:
编译运行,然后在控制台输入想要的东西,呵呵,成功了。沉浸在幸福中的你得意忘形了吧。 |
发布日期: 六, 18 八月 2007 06:02:01 GMT
计算机与 Internet |
阅读完整项
简单工厂模式与工厂方法模式 (ZZ)
在OO设计领域,我们知道前人总结了不少的经验,许多的经验在现代软件工程过程中已经被认为是原则来遵守。下面笔者摘抄几项下文涉及到的OO原则的定义。
以上就是简单工厂模式的一个简单实例,读者应该想象不用接口不用工厂而把具体类暴露给客户端的那种混乱情形吧(就好像没了体育总局,各个俱乐部在市场上自己胡乱的寻找仔细需要的运动员),简单工厂就解决了这种混乱。 我 们用OCP看看简单工厂,会发现如果要对系统进行扩展的话治需要增加实现产品接口的产品类(上例表现为“足球运动员”,“篮球运动员”类,比如要增加个 “乒乓球运动员”类),而无需对原有的产品类进行修改。这咋一看好像满足OCP,但是实际上还是需要修改代码的——对,就是修改工厂类。上例中如果增加 “乒乓球运动员”产品类,就必须相应的修改“体育协会”工厂类,增加个“注册乒乓球运动员”方法。所以可以看出,简单工厂模式是不满足OCP的。 工厂方法模式及其实例 谈 了简单工厂模式,下面继续谈谈工厂方法模式。前一节的最末点明了简单工厂模式最大的缺点——不完全满足OCP。为了解决这一缺点,设计师们提出了工厂方法 模式。工厂方法模式和简单工厂模式最大的不同在于,简单工厂模式只有一个(对于一个项目或者一个独立模块而言)工厂类,而工厂方法模式有一组实现了相同接 口的工厂类。下面我们通过修改上一节的实例来介绍工厂方法模式。 我们在不改变产品类(“足球运动员”类和“篮球运动员”类)的情况下,修改下工厂类的结构,如下图所示: 相关代码如下:
很明显可以看到,“体育协会”工厂类变成了“体育协会”接口,而实现此接口的分别是“足球协会”“篮球协会”等等具体的工厂类。 这样做有什么好处呢?很明显,这样做就完全OCP了。如果需要再加入(或扩展)产品类(比如加多个“乒乓球运动员”)的话就不再需要修改工厂类了,而只需相应的再添加一个实现了工厂接口(“体育协会”接口)的具体工厂类。 从以上对两种模式的介绍可以了解到,工厂方法模式是为了克服简单工厂模式的缺点(主要是为了满足OCP)而设计出来的。但是,工厂方法模式就一定比简单工厂模式好呢?笔者的答案是不一定。下面笔者将详细比较两种模式。 1. 结构复杂度 从这个角度比较,显然简单工厂模式要占优。简单工厂模式只需一个工厂类,而工厂方法模式的工厂类随着产品类个数增加而增加,这无疑会使类的个数越来越多,从而增加了结构的复杂程度。 2.代码复杂度 代码复杂度和结构复杂度是一对矛盾,既然简单工厂模式在结构方面相对简洁,那么它在代码方面肯定是比工厂方法模式复杂的了。简单工厂模式的工厂类随着产品类的增加需要增加很多方法(或代码),而工厂方法模式每个具体工厂类只完成单一任务,代码简洁。 3.客户端编程难度 工厂方法模式虽然在工厂类结构中引入了接口从而满足了OCP,但是在客户端编码中需要对工厂类进行实例化。而简单工厂模式的工厂类是个静态类,在客户端无需实例化,这无疑是个吸引人的优点。 4.管理上的难度 这是个关键的问题。 我 们先谈扩展。众所周知,工厂方法模式完全满足OCP,即它有非常良好的扩展性。那是否就说明了简单工厂模式就没有扩展性呢?答案是否定的。简单工厂模式同 样具备良好的扩展性——扩展的时候仅需要修改少量的代码(修改工厂类的代码)就可以满足扩展性的要求了。尽管这没有完全满足OCP,但笔者认为不需要太拘 泥于设计理论,要知道,sun提供的java官方工具包中也有想到多没有满足OCP的例子啊(java.util.Calendar这个抽象类就不满足 OCP,具体原因大家可以分析下)。 然后我们从维护性的角度分析下。假如某个具体产品类需要进行一定的修改,很可能需要修改对应的工厂类。当同时 需要修改多个产品类的时候,对工厂类的修改会变得相当麻烦(对号入座已经是个问题了)。反而简单工厂没有这些麻烦,当多个产品类需要修改是,简单工厂模式 仍然仅仅需要修改唯一的工厂类(无论怎样都能改到满足要求吧?大不了把这个类重写)。 由以上的分析,笔者认为简单工厂模式更好用更方便些。当然这只是笔者的个人看法而已,毕竟公认的,工厂方法模式比简单工厂模式更“先进”。但有时过于先进的东西未必适合自己,这个见仁见智吧。 |
发布日期: 五, 17 八月 2007 09:39:37 GMT
计算机与 Internet |
阅读完整项
简话设计模式 (ZZ)
简话设计模式 |
作者:杨宁(来自grapecity) 原文地址:http://www.uml.org.cn/sjms/200432950.htm |
第一章 引言 1. 本文不适合… 本文不适合面向对象编程高手,会浪费你的时间。如果你愿意抽出时间来阅读本文,并提出宝贵的建议,非常感谢!什么?你没有听说过设计模式?那你也敢称高手? 2. 本文适合… 我第一次读这本书是在 每次晚睡之前,几乎每次都先睡着。《设计模式》以一种严谨,系统化的风格来论述23种设计模式,原书可以说是面向对象编程的一个基础教程,但是要领会其精 髓,必须要花费一定的精力。本文的目的是为了帮助你更加方便地理解每一种设计模式,并不想成为原书的替代读物。 本文无意于介绍面向对象的基本知识。因此,假设本文的读者已经对面向对象的封装性、继承性和多态性有足够的了解和认识。并能够认识到可复用的面向对象设计的两个原则:
3. 设计模式是什么? 我们可以简单的认为:设计模式就是解决某个特定的面向对象软件问题的特定方法。但严格的来说上述的认识是不准确的,难道面向对象软件中只有区区23个问题?当然不是。 为了能够更加准确地理解这个概念,我们引入另外一个术语:框架(Framework)。框架这个词汇在当今有了各种各样的应用和含义。在设计模式中:框架(Framework)是构成一类特定软件可复用设计的一组相互协作的类。 框架可以认为是一个适用于某个领域的软件包。这个软件包提供了相应领域的各个问题的解决方法。那么,它和设计模式有什么区别?
Tips:设计模式就像是在武功中基本的招式。我们将这些招式合理地组合起来,就形成套路(框架)。 4. 为什么要用设计模式? 第二章 概要简介 在《设计模式》一书中,共包含23个模式。根据目的的不同,将它们分为三类:
Tips:设计模式中经常会用到抽象(Abstract)和具体(Concrete)这两个词。抽象的含义是指它所描述的类(方法)是接口类(方法),具体的含义是指它所描述的类(方法)实现了相应的抽象类(方法)。 第三章 抽象工厂(Abstract factory) 1. 意图 2. 分类 3. 问题是什么? 房 子是由墙,门,窗户,地板,天花板,柱子组成的。如果我们为客户编写一个建造房子的软件,我们会把墙,门,窗户,地板,天花板,柱子看成不同的类: WallClass, DoorClass, WindowClass, CeilingClass, PillarClass。 现在我们建立一个新类 A,这个类中有CreateWall(), CreateDoor(), CreateFloor(), CreateCeiling(), CreatePillar()五个方法,每个方法的功能就是创建并返回相应的对象。如果把WallClass, DoorClass, WindowClass, CeilingClass, FloorClass, PillarClass的实例看成产品的话,那么类A就像是一个生产这些产品的工厂。这就是使用工厂这个词的原因。 Tips:A这个名字太糟,如果用HouseFactory会好一些。一般情况下,在你的系统使用某个模式,最好使用模式相应的关键字作为类或者方法的名字的一部分,这样,你的同伴或者系统的代码维护者就会明白你的用意。 我们的软件完成了,客户非常满意。不过,我们的客户想把这个软件出口,他发现一个问题,这个软件太本地化了,建造出来的都是中国式的房屋。因此他希望我们的软件能够建造出不同地域风格的房子。 这就是我们的问题!我们需要重新设计原系统,而且一次完成世界各地不同建筑风格是不可能的。我们会先完成部分风格(客户第一要投放软件的国家的),然后再增加其他的… 4. 解决方法
2) 建立相应的抽象产品(Abstract Product)类集: Wall, Door, Floor, Ceiling, Pillar 3) 为不同风格建立相应的具体工厂(Concrete Factory)类(不要忘了实现关系),例如:
4) 为不同的风格建立相应的具体产品(Concrete Product)类(实现相应的抽象产品),例如:
5. 杂谈
抽象工厂模式的重点不是声明的那个抽象工厂类,而是它声明的一系列抽象产品类,我们通过使用这些抽象产品类可以操作我们已经实现或者还未实现的具体产品类,并且保证了它们的一致性。 你 可能已经发现这个软件不能建造你的两层别墅,因为它没有楼梯。为此,我们要定义Stair抽象类,还要增加CreateStair抽象方法;最重要的是我 们要在已经完成的76种风格中增加相应的Stair类,这可是个大麻烦。确实,抽象工厂模式在适应新的产品方面的能力是比较弱的。这是它的一个缺点。 第四章 生成器(Builder) 1. 意图 2. 分类 3. 问题是什么? 4. 解决方法 1) 创建一个生成器(Buider)类:
在这个类中,我们对每一种房屋组成元素都定义了一个Build方法。并且定义了一个返回构造结果的方法GetHouse。 2) 对每一种风格都定义一个具体的生成器(Concrete Builder)类:
并且在这些类中重载父类的方法。 3) 还有,各种类型的房屋类:
5. 如何使用
只要向通过HouseSystem.Create方法传入不同的生成器就可以得到不同风格的结果。 事实上,HouseSystem也是生成器模式的一个参与者,叫做导向者(Director)。注意的问题:
6. 杂谈
● 将系统的文档格式转换到其他的格式上(每一种格式的文档都相当于一个产品)。 |
发布日期: 一, 13 八月 2007 14:15:10 GMT
计算机与 Internet |
阅读完整项
C++/CLI中实现singleton模式
C++/CLI中实现singleton模式
1 #pragma once 2 3 /** \class sidle::Singleton 4 \brief Singleton (Double-Checked Locking) 5 \author 吴尔平 6 \version 1.0 7 \date 2005.02.08 - 8 \bug 9 \warning 10 */ 11 12 namespace sidle 13 { 14 using namespace System; 15 using namespace System::Threading; 16 17 template<typename _T> 18 ref class Singleton 19 { 20 public: 21 static _T^ Instance() 22 { 23 if (_instance == nullptr) 24 { 25 _mut->WaitOne(); 26 try 27 { 28 if (_instance == nullptr) 29 { 30 _instance = gcnew _T(); 31 } 32 } 33 finally 34 { 35 _mut->ReleaseMutex(); 36 } 37 } 38 return _instance; 39 } 40 protected: 41 Singleton(){} 42 static _T^ _instance; 43 static Mutex^ _mut = gcnew Mutex(); 44 }; // ref class Singleton 45 46 }; // namespace sidle |
发布日期: 一, 13 八月 2007 05:35:44 GMT
计算机与 Internet |
阅读完整项
C++/CLI:第一流的CLI语言 (ZZ)
C++/CLI:第一流的CLI语言
本文并不是为了奉承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 CLIGC类R1和R2,二者都实现了Idisposable接口且都有函数F(),还有一个CLIGC类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/deleteCLI类型,而且也能够在CLI堆上gcnew/delete本机类型。但既然这是Whidbey以后的东西,本文不讨论统一模型。
在我谈论你何时使用混合类型以前,我想向你说明什么是混合类型。如果你理解混合类型,请跳过下面几段。这里引用BrandonBray的说法:"一种混合类型,或者是本机类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中声明,但是你要用"#includevcclr.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哈希结果。你的队友正在悲叹他们将必须花费几个小时钻研cryptoAPI,而你的上司在担忧你们可能必须要买一个第三方加密库;那正是你在他们面前树立形象的时候,你宣布你将在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)
下面代码展示了别针型指针的应用。
#pragma unmanaged //本机函数,以整型指针作参数,执行计算 void calc(int* val) { //执行计算操作 } #pragma managed //托管函数调用本机calc函数 int managedfunc() { int i=gcnew int(10); //把i的地址设置为别针型,以阻止对i的移动 pin_ptr<int> ppi=&i; int* np=ppi; calc(np);//用别针型int的地址调用本机函数 //把别针型指针的值置为nullptr,脱离了gc的限制 ppi=nullptr; //完成剩下的工作 return i; } |
基于轮廓的优化(Profile Guided Optimization)
在新版本的托管C++中有一项新增功能称为基于轮廓的优化。这一新的编译特点能够实现在编译时刻把探针注入到代码中。最后的exe文件与一个数据库一起打包发送,由该库记录下注入代码中的探针监测到的结果数据。当用户运行该程序时,这些探针记录下应用程序的使用。当你下一次再编译时,编译器作出智能性决策,如根据探针的记录作为相应的动作。这一特性带来了真实世界的优化。
为什么没有为使用托管类型而定义头文件?
在传统的C++中,一个头文件一般包含对象的接口,或者类与函数的声明,等等。这允许在多个翻译单元上实现某种类型的一致性声明。对于一个用托管代码编写的且其被编译成MSIL的对象,需要在配件集中包含描述对象的元数据。因而,托管C++编译器不是通过头文件,而是通过使用配件集元数据来实现接口的读取。这就是为什么你不必因使用托管类型而包含头文件。事实上,你可以通过使用#using指令来让编译器从配件集中读取元数据。
发布日期: 一, 13 八月 2007 03:39:32 GMT
计算机与 Internet |
阅读完整项
托管代码中的指针 (ZZ)
RefclassRtest{}
Vtest^vtest=gcnewVtest;//值类型对象
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=gcnewRTest;//引用类型对象
pin_ptr<Rtest>pinp;//error,不可以钉住引用类型对象
interior_ptr<Rtest>pinp;//error,不可以指向引用类型对象
refclassG{
public:
voidincr(int*pi){*pi+=1;}
};
refstructH{intj;};
voidf(G^g){
H^ph=gcnewH;
Console::WriteLine(ph->j);
pin_ptr<int>pj=&ph->j;//ok,可以钉住引用类型对象的成员
g->incr(pj);
Console::WriteLine(ph->j);
}
{
public:
inti;
};
#pragmaunmanaged
voidincr(int*i)
{
(*i)+=10;
}
#pragmamanaged
voidmain()
{
Test^test=gcnewTest();
interior_ptr<int>ip=&test->i;
(*ip)=5;
//incr(ip);//invalid
pin_ptr<int>i=ip;//iisapinnedintpointer
incr(i);//pinnedpointertointeriorpointerpassedtoa
//nativefunctioncallexpectinganativepointer
Console::WriteLine(test->i);
}
ClassValue*p=pValue;//ok
ClassValue*p=pValue;//error
发布日期: 一, 13 八月 2007 02:21:40 GMT
计算机与 Internet |
阅读完整项
C++/CLI思辨录之再谈继承 (ZZ)
C++/CLI思辨录之再谈继承
在OO和C++中,类成员共有三种级别的继承:public,protected和private。对于基类成员的存取操作应该依赖于下面两个因素:
·派生类声明其类头(public, protected 或 private)的方式
·对类成员的存取指定标志(public, protected 或 private)
如果你在基类中声明成员为private,那么这些成员对于任何派生类都是不可存取的。
如果你在基类中声明成员为protected,而且新类是基类的私有派生,那么这些成员在派生类中变为私有的。
如果你在基类中声明成员为protected,而且新类是基类的protected 型派生,那么这些成员在派生类中变为protected 的。
如果你在基类中声明成员为protected,而且新类是基类的public 型派生,那么这些成员在派生类中变为protected的。
如果你在基类中声明成员为public,而且新类是基类的private 型派生,那么这些成员在派生类中变为private 的。
如果你在基类中声明成员为public,而且新类是基类的protected 型派生,那么这些成员在派生类中变为protected的。
如果你在基类中声明成员为public,而且新类是基类的public 型派生,那么这些成员在派生类中变为public 的。
这是一些老式的C++规则。在.Net中,情况就大大不同了-.Net仅支持public继承。但是当一个类被public继承,则基类的保护成员将对新的派生类成为private的。
考虑下面的三个C++类:
class A { protected: void fa() { printf("fa called"); } }; class B : public A { public: void fb() { fa(); } }; class C : public B { public: void fc() { fa(); } }; int main() { C c; c.fc(); return 0; } |
根据我前面介绍的规则,在C++中这些代码是能成功运行的。但是如果你把它们改变为托管类,则在类c中是不能调用fa()的。
发布日期: 五, 10 八月 2007 08:20:49 GMT
计算机与 Internet |
阅读完整项
C++/CLI思辨录之内部指针的两面性 (ZZ)
C++/CLI思辨录之内部指针的两面性
using namespace System; int _tmain() { int ^ hnd = gcnew int(100); int* np = &hnd; // Genarates a compile error } |
但是本地指针还是非常有用的,如在使用指针算术和指针比较时就有许多的优点。所以新的C++CLI允许你使用一个内部指针实现同样的功能。内部指针是本地指针的一个超集。所以它能够做任何内部指针所能做的一切。但是当垃圾收集器移动指针所指向的对象时,内部指针也帮助程序实现其指向的地址的更新。
现在让我们看一下如何用内部指针来实现指针算术运算。
#include "stdafx.h" #include <stdio.h> using namespace System; using namespace stdcli::language; int _tmain() { const int SIZE = 10; array<int>^ arr = gcnew array<int>(SIZE); for(int idx = 0; idx < SIZE; idx++) { arr[idx] = idx + 1; } // 取得指向数组第一个元素的指针 interior_ptr p = &arr[0]; // 通过增加指针值读取并输出数组元素 for(int idx = 0; idx < 10; idx++) { printf("Value of the element at %Xh ", p); Console::WriteLine(" is {0}",*(p++)); } Console::ReadLine(); } |
不管垃圾收集器执行多少次和数组元素移动多少次,上面的代码仍然能工作良好。于是C++的力量又回到了.Net运行时刻库上。但是要小心使用内部指针。这些指针与本地指针非常相似,当试图存取不允许操作的内存区段时能给程序造成危害。例如,如果我在上面的代码中试图存取下一个p++,它将返回恰好在上面数组元素上方4字节的内存段位置
发布日期: 五, 10 八月 2007 07:51:18 GMT
计算机与 Internet |
阅读完整项
C++/CLI思辨录之代理构造函数 (ZZ)
C++/CLI思辨录之代理构造函数
对一个类来说,有多个构造函数是经常的事;并且这多个构造函数有一段共同的代码也很经常。一般地,在这种情况下,我们都是为该共同代码段编写一个独立的函数,然后放在每个构造器中调用。如下例:
class Foo { private: int _mem; public: Foo() : _mem(0) { CommonConstructor(); } Foo(int mem) : _mem(mem) { CommonConstructor(); } Foo(const Foo& f) : _mem(f._mem) { CommonConstructor(); } // 我们所有的构造器都需要的代码段 void CommonConstructor() { printf("Constructing the object"); } }; |
但是现在利用C++/CLI引入的新特性-代理构造器,我们可以从一个称为基类构造器的构造器中调用另一个构造器。当你这样做时,执行控制转入到第二个构造器中,在其执行完后再返回到第一个构造器。下面代码片断中的类Foo2演示了这种方法:
class Foo2 { private: int _mem; public: // 该构造器调用第二个称为基类构造器的构造器 Foo2() : Foo2(0) { } // 下面这个构造器包含由所有构造器使用的公共代码 Foo2(int mem) : _mem(mem) { printf("Constructing the object"); } Foo2(const Foo2& f) : Foo2(f._mem) { } }; |
然而,每个类都应该包含至少一个非代理构造器,不过该构造器仍然可以有调用一个或者多个基类构造器的初始化操作。
注意,早期情况下,如果你想试用一下代理构造函数,应该会出现一个编译错误。请注意,这是由于资源问题缺乏导致的,在现在版本的C++/CLI中可以避免这一错误。
发布日期: 五, 10 八月 2007 05:05:41 GMT
计算机与 Internet |
阅读完整项
C++/CLI思辨录之拷贝构造函数 (ZZ)
C++/CLI思辨录之拷贝构造函数
#include <stdio.h> #include <string.h> class Person { private: char* _name; public: Person() { _name = new char[256]; } void SetName(const char* name) { if(strlen(name) + 1 < 256) strcpy(_name,name); } void PrintName() { printf("%s\n",_name); } }; int main() { // 创建对象的第一个实例并赋于名字为John Person p1; p1.SetName("John"); p1.PrintName(); //通过复制p1引用的对象创建另一个对象 Person p2(p1); p2.SetName("Alice"); p2.PrintName(); //现在再输出p1的名字 p1.PrintName(); scanf("q"); return 0; } |
这里的类Person有一个指向在堆上分配的字符数组的指针。当构造Person对象时,它创建该字符数组并把它的位置存放到变量_name中。
但是当你创建Person 对象 p2 时,p2的成员用p1的成员初始化。因而,p1的 _name与p2的_name指向相同的堆对象。如在上例中看到的,调用p2.SetName将改变由这两个类共享的值。所以,当第二次调用p1.PrintName,打印结果是"Alice"。
所以,这不是我们复制对象所期望的结果,而且还会导致堆崩溃的问题。请再考虑某个函数删除了该数组而p1又要调用该函数的情况?下面,当p2调用PrintName时,它将尽量存取实际上不是在堆上的对象。这种情况下产生的结果往往是难以预料的。
C++允许我们通过定义拷贝构造函数来克服这类问题。在我们每次通过复制另一个对象来初始化一个对象时,拷贝构造函数都被执行。你可以在拷贝构造函数中覆盖掉缺省的成员函数的复制行为。
所以,我们的类Person应该修改如下:
class Person { private: char* _name; public: Person() { _name = new char[256]; } // 这是拷贝构造函数。在此我们初始化一个新的数组,为Person的实例所用 Person(Person&) { _name = new char[256]; } void SetName(const char* name) { if(strlen(name) + 1 < 256) strcpy(_name,name); } void PrintName() { printf("%s\n",_name); } }; |
这里类Person中的拷贝构造函数保证了它初始化一个新的数组,为在复制时产生的每一个对象实例所用。这就避免了前面我们提到的问题。
希望上面所述能够帮助读者理解拷贝构造函数及其使用场所。
发布日期: 五, 10 八月 2007 03:55:02 GMT
计算机与 Internet |
阅读完整项
浅议C++/CLI的gcnew关键字 (ZZ)
浅议C++/CLI的gcnew关键字
1. gcnew返回的是一个句柄(Handle),而new返回的是实际的内存地址.
using namespace System;
ref class Foo
{
public:
Foo()
{
System::Console::WriteLine("Foo::Foo");
}
~Foo()
{
System::Console::WriteLine("Foo::~Foo");
}
public:
int m_iValue;
};
int _tmain()
{
int* pInt = new int;
int^ rInt = gcnew int;
Foo^ rFoo = gcnew Foo;
delete rFoo;
delete rInt;
delete pInt;
}
|
int* pInt = new int;
0000004c mov ecx,4
00000051 call dword ptr ds:[03B51554h]
00000057 mov esi,eax
00000059 mov dword ptr [esp+18h],esi
int^ rInt = gcnew int;
0000005d mov ecx,788EF9D8h
00000062 call FCFAF66C
00000067 mov esi,eax
00000069 mov dword ptr [esi+4],0
00000070 mov edi,esi
Foo^ rFoo = gcnew Foo;
00000072 mov ecx,3B51768h
00000077 call FCFAF66C
0000007c mov esi,eax
0000007e mov ecx,esi
00000080 call dword ptr ds:[03B517ACh]
00000086 mov dword ptr [esp+1Ch],esi
delete rFoo;
0000008a mov ebx,dword ptr [esp+1Ch]
0000008e test ebx,ebx
00000090 je 000000A4
00000092 mov ecx,ebx
00000094 call dword ptr ds:[03FD0028h]
0000009a mov dword ptr [esp+14h],0
000000a2 jmp 000000AC
000000a4 mov dword ptr [esp+14h],0
delete rInt;
000000ac mov edx,edi
000000ae mov ecx,788F747Ch
000000b3 call FC8D20FD
000000b8 mov ebp,eax
000000ba test ebp,ebp
000000bc je 000000D0
000000be mov ecx,ebp
000000c0 call dword ptr ds:[03FD0020h]
000000c6 mov dword ptr [esp+10h],0
000000ce jmp 000000D8
000000d0 mov dword ptr [esp+10h],0
delete pInt;
000000d8 mov ecx,dword ptr [esp+18h]
000000dc call dword ptr ds:[03B51540h]
|
int* pInt = new int;
0000004c mov ecx,4
00000051 call dword ptr ds:[03B51554h]
|
可以看到,和以前在vc6中一样,分配内存的步骤如下:
成功分配后,会把返回地址放在eax中。
int^ rInt = gcnew int;
0000005d mov ecx,788EF9D8h
00000062 call FCFAF66C
。。。
Foo^ rFoo = gcnew Foo;
00000072 mov ecx,3B51768h
00000077 call FCFAF66C
|
可以看到gcnew也是通过把一个参数放到ecx中,然后再调用一个函数来完成分配的操作,显然0x788EF9D8应该是一个地址,而不可能是一个数值。我们可以看到这里gcnew创建两个不同类型的变量,调用的函数地址却都是0xFCFAF66C,而存放到ecx中的两个地址就不一样。究竟这几个地址代表什么呢?
这次的eax = 0x00F73404 对应的内存块为
0x00F73404 d8 f9 8e 78 00 00 00 00 。。。
|
OBJECTREF AllocateObject( MethodTable *pMT )
在我们的例子里面两个call的地址都一样,但是你如果写下代码 double ^ pDouble = gcnew double;这个时候的地址是多少?它和int 的一样么?
目前我还没有仔细去研究这个地址到底对应的是该类型的MethodTable::Allocate()或是上面的这三个全局函数,如果对应MethodTable::Allocate(),那么2.0中应该有个MethodTable::FastAllocate()吧,否则应该就是对应的全局函数AllocateObject 以及FastAllocateObject了。过几天一定要抽空再好好研究一下。
delete pInt;
000000d8 mov ecx,dword ptr [esp+18h]
000000dc call dword ptr ds:[03B51540h]
比较简单,就是传入地址,然后调用operator delete来释放类存,会调用析构函数
|
delete rInt;
000000ac mov edx,edi
000000ae mov ecx,788F747Ch
000000b3 call FC8D20FD
|
这个也相对简单,它对应vm里面的一个函数:
那么也就是
发布日期: 五, 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)
C++/CLI中栈对象的设计问题
这的确不错,相对而言,这个比 C#中的using 关键字(dispose模式),以及Java中的hard-coded的dispose方法都要好许多。这个特性是由C++/CLI中栈对象(局部对象)来提供的,局部对象本身没错,RAII也是局部对象应有之义。
但问题在于C++/CLI中栈对象的可用性由于许多原因会大打折扣,使用起来已经远远不如ISO-C++中那样流畅。下面列出了损伤其可用性的几大硬伤:
#1、C++/CLI的栈对象并非真的位于栈中
只要类型是ref class,C++/CLI中的栈对象就仍位于 托管堆中。仍然使用newobj IL指令来分配。如果R没有定义析构器(~R)(注意:C++/CLI中的析构器和 C#中的析构器完全两回事),那么下面两行代码实际上将生成完全一样的IL代码:
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=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)
C++/CLI基本数据类型探索
C++/CLI所支持的基本类型,例如int、double、bool等,在某些方面可以说是沿袭了ISO-C++中的类型——同样的用法会在C++/CLI中得到同样的结果,例如加法或者赋值操作。但是C++/CLI也为这些基本类型引入了一些新的东西。
在通用类型系统(CTS)中,每一个基本类型都在System命名空间中存在一个对应的类(见表1)。例如int实际上完全等价于System::Int32。我们可以使用二者中的任何一个来声明一个整数:
int ival = 0; Int32 ival2 = 0; |
出于移植性的考虑,在使用这些基本类型时,我们推荐大家使用内建的关键词,而非System命名空间中的类名。
基本类型 | System命名空间中对应的类 | 注释/用法 |
bool | System::Boolean | bool dirty = false; |
char | System::SByte | char sp = ' '; |
signed char | System::SByte | signed char ch = -1; |
unsigned char | System::Byte | unsigned char ch = '\0'; |
wchar_t | System::Char | wchar_t wch = ch; |
short | System::Int16 | short s = ch; |
unsigned short | System::UInt16 | unsigned short s = 0xffff; |
int | System::Int32 | int ival = s; |
unsigned int | System::UInt32 | unsigned int ui = 0xffffffff; |
long | System::Int32 | long lval = ival; |
unsigned long | System::UInt32 | unsigned long ul = ui; |
long long | System::Int64 | long long etime = ui; |
unsigned long long | System::UInt64 | unsigned long long mtime = etime; |
float | System::Single | float f = 3.14f; |
double | System::Double | double d = 3.14159; |
long double | System::Double | long double d = 3.14159L; |
对于System命名空间中类的公有静态成员,我们既可以通过内建的关键字,也可以通过System命名空间中的类名来访问。例如,为了获取一个数值类型的取值范围,我们可以直接使用内建的关键字来访问其静态属性MaxValue和MinValue。
int imaxval = int::MaxValue; int iminval = Int32::MinValue; |
每个数值类型都支持一个名为Parse的成员函数,用以将一个字符串转化为其所表示的数值。例如,给定下面的字符串:
String^ bonus = "$ 12,000.79"; |
调用Parse会将myBonus初始化为12000.79:
double myBonus = double::Parse( bonus, ns ); |
其中ns表示对一些NumberStyles枚举类型取位或(bitwiseor)运算的结果。NumberStyles是位于System::Globalization命名空间中的一个枚举类型,用于表征对空白、货币符号、小数点或者逗号等的处理。看下面的代码:
using namespace System; using namespace System::Globalization; double bonusString( String^ bonus ) { NumberStyles ns = NumberStyles::AllowLeadingWhite; ns |= NumberStyles::AllowCurrencySymbol; ns |= NumberStyles::AllowThousands; ns |= NumberStyles::AllowDecimalPoint; return double::Parse( bonus, ns ); } |
我们也可以使用转型符号来在类型间进行显式的转换。
int ival = ( int ) myBonus; |
或者使用System::Convert类的一些转换方法,例如ToDouble(), ToInt32(), ToDateTime()等:
int ival2 = Convert::ToInt32( myBonus ); |
两种转换方法采用的策略有所不同:显式转型会直接对小数部分进行截断,而Convert的成员函数则采用的是舍入算法。例如上面的例子中ival赋值后的结果为12000,而ival2赋值后的结果为12001。
我们还可以直接使用字面常量(literal)来调用其对应类型的成员函数,虽然这乍看起来有些怪异。例如,我们可以编写如下代码:
Console::Write( "{0} : ", ( 5 ).ToString() ); |
其中( 5).ToString()返回的是字面常量整数5的字符串表示。注意5外面的圆括号是必须的,因为它会使得编译器将后面的成员选择操作符点号绑定到整数5上,而不是将'5.'解析为一个double类型的字面常量——那样的话,后面的ToString()将变得不合法。为什么我们有时候需要这样做呢?一种可能的情况是将一个字符串传递给Console的成员函数要比传递实际的数值来的更加高效。
对于字符以及字符串这样的字面常量,我们也可以像上面的整数一样调用它们的成员函数,但是它们的行为有一点点晦涩。例如,下面的代码:
Console::WriteLine(( 'a' ).ToString() ); |
将在控制台上打印出97,而非'a'这个字符。要将字符'a'打印出来,我们需要将其首先转型为System::Char:
Console::WriteLine(((wchar_t)'a').ToString() ); |
C++/CLI对字符串字面常量采取了特殊的处理策略。从某种程度上来讲,字符串字面常量在C++/CLI中的类型更接近System::String,而非C风格的字符串指针。显然,这将对重载函数的辨析产生影响。例如:
public ref class R { public: void foo( System::String^ ); // (1) void foo( std::string ); // (2) void foo( const char* ); // (3) }; void bar( R^ r ) { // 调用哪一个foo呢? r->foo( "Pooh" ); } |
一个重载函数的辨析过程通常包含以下三个步骤:
1.选择候选函数集合。候选函数是指那些从词法范畴来看与所调用函数名相匹配的函数。例如,由于我们上面是在R的一个实例上调用foo(),所以所有名称为foo但却不是R或者其基类的成员的那些函数将不被认为是候选函数。这样看来,我们现在有三个候选函数,即R中三个名称为foo的成员函数。如果这个阶段得到的候选函数集合为空,那么调用将告失败。
2.从候选函数集合中选择可用函数集合。可用函数是指函数声明时的参数个数和它们的类型与调用时所指定的相匹配的那些函数。在我们上面的例子中,三个候选函数都是可用函数。如果这个阶段得到的可用函数集合为空,那么调用也将失败。
3.从可用函数集合中选择最匹配的函数。这个阶段将会对实际传递的参数和可用函数所声明的参数之间的转换进行一个排名。对于只含一个参数的函数来说,这个过程比较简单。但是对于含有多个参数的函数来说,这个过程就变得相对有些复杂。如果没有一个最佳的匹配函数胜出,那么调用将告失败。也就是说各个可用函数的参数类型到实际参数类型之间的转换被认为一样的好,换言之多个调用之间产生了混淆。
那么现在摆在我们面前有两个问题:(1)我们实际传递的参数"Pooh"到底是什么类型?(2)在判定类型转换的优劣时采用的是什么算法?
在ISO-C++中,字符串字面常量"Pooh"的类型为constchar[5]——注意,在字符串字面常量后面有一个隐含的截断字符null。在上面的例子中显然不存在这样的精确匹配,因此必须应用某种形式的类型转换。这样,两个ISO-C++候选函数(2)和(3)将进行竞争:
void foo( std::string ); // (2) void foo( const char* ); // (3) |
那么编译器如何从中判断可用函数呢?C++语言对类型转换按照优先顺序定义有一个层级结构,在这个结构中,如果一种转换优于另一种转换,那么它将被排在前面。在C++/CLI中,我们将CLI类型的行为也集成到了ISO-C++的标准类型转换层级结构中。下面是对集成之后的层级结构的一个描述:
1)精确匹配是最好的。需要注意的是精确匹配并不意味着实际传递的参数类型和函数声明的形式参数类型完全匹配。它们只需要“足够接近”就可以了。我们下面将会看到,“足够接近”对于ISO-C++和C++/CLI中的字符串字面常量有着一些不同的含义。
2)在标准转换中,拓宽转换要优于非拓宽转换。例如,将short拓宽为int要优于将int转换为double。
3)标准转换优于装箱(boxing)转换。例如,将int转换为double优于将int装箱为Object。
4)装箱转换优于用户自定义的隐式转换。
5)用户自定义的隐式转换优于没有任何转换!
6)否则,用户必须使用显式的转型符号来表示期望的转换。
对于上面两个ISO-C++下的候选函数,将字符串字面常量转换为一个std::string属于上面第5条,即隐式调用string的构造器来创建一个临时string对象。而将字符串字面常量转换为一个const char* 属于上面第1条。第1条优于第5条,因此,参数为constchar*的那个函数在这场竞争中胜出。
这种归属在第1条“精确匹配”下的trivialconversions实际上在技术的定义上是很严格的。总共有4种这样的trivialconversions可以被归为精确匹配。即使在这4种trivialconversions中,为了规范语言对类型的选择,它们也有一个优先级的排序。
大多数读者和程序员可能对于这样的细节没有多大兴趣,并且通常情况下我们也无须深入到这些细节的地方。但是如果我们要得到一个直观的语言行为、并且确保它们在不同的实现上表现相同,这些规则的存在就很有必要。这是因为作为一门编程语言,它的行为一般要具有某种程度的“类型感知”能力,从而允许程序员忽略这些细节。 下面让我们来对这4种trivialconversions做一简单的了解。其中3种被称为左值转换(lvaluetransformation)。左值(lvalue)是一个可寻址的,可被执行写操作的程序实体。第4种为限定性转换(qualificationconversion),例如,在一个类型声明上加一个const修饰符就属于这种转换。其中3种左值转换优于限定性转换。
在我们上面的例子中,由本地数组到指针的转换,即由const char [5]到const char *,就是一种左值转换。在大多数情况下,我们甚至不将这看作一种转换。
这种形式的左值转换在C++/CLI中仍然适用,但是在我们将System::String类引入之后,字符串字面常量到constchar*的转换就不再是最好的匹配了。实际上,在C++/CLI中,"Pooh"这样的字符串字面常量的类型既是constchar[5](C++/CLI对本地类型系统保留后的结果),同时也是System::String(C++/CLI中的托管类型)。这样,在C++/CLI中,字符串字面常量和System::String类型之间是一个精确的匹配,它优于由字符串字面常量到constchar*的trivial conversion。
有些朋友看到这里,可能会不高兴,“为什么要这样做?难道ISO-C++对字符串字面常量的处理不能满足C++/CLI的绑定需要吗?”C++/CLI这样做的理由在于字符串字面常量是我们程序中的一个基本元素,而ISO-C++的行为在很多情况下显得并不直观。实际上,这些规则在我们现在看到的结果之前的一年中被来来回回改了3次之多。
这反映了ISO-C++和C++/CLI在对待各自的类型系统时存在的一个基础性差异。在ISO-C++中,除非是显式存在于一个类库中,否则类型就是独立的。因此,在字符串字面常量和std::string之间并没有隐含的类型关系,虽然它们共享着同一个抽象域(domain)。
但是在C++/CLI中,我们支持统一的类型系统。每一个类型,包括字面常量值,都是一个Object的子类。这也是我们为什么可以在一个字面常量值,或者内建类型的对象上直接调用方法的原因。整数字面常量5的类型为Int32,字符串字面常量"Pooh"的类型为String。认为字符串字面常量更接近C风格的字符串,或者就把它看作C风格的字符串是不合适的。
集成后的类型转换层级结构使得一个正常运行的ISO-C++程序在使用/clr编译器开关重新编译后仍能展现同样的行为,但是使用CLI类型的新的C++/CLI程序在处理字符串字面常量时将会体现新的类型优先排序规则。这段讨论的长度相对于这个主题的重要性而言可能并不合适,但是它却向大家揭示了我们到底在将CLI类型系统和ISO-C++语义框架集成在一起的时候,做了哪些工作,以及如何在必要的时候调整在集成过程中所出现的各个情况的优先级。同时,这也提醒大家在将一个本地类重新构造为一个CLI类的过程中需要注意的一些问题。比如有些情况下我们最好要对那些接受字符串字面常量的成员函数进行新的设计,而不是简单地将一个参数为String的函数添加到这些重载函数集合中了事。
另外需要注意的是,String表示的是Unicode字符集。和ASCII字符集不同,这需要两个字节来表示一个字符。虽然在C++/CLI中字符串字面常量的类型为String,但这并不意味着在C++/CLI中,一个字符串字面常量必然会被解析为双字节的字符流。在本地C++中,我们要在字符串字面常量前加一个L来告诉编译器将其看作一个双字节的字符流。在C++/CLI中,我们仍然需要这么做。
发布日期: 四, 09 八月 2007 07:39:38 GMT
计算机与 Internet |
阅读完整项
CLI类型声明比较 (ZZ)(节选)
八、声明类型 CLR类型有一个形容词前缀用来说明类型的种类,下面是C++/CLI中的类型声明示例: 1、 CLR types
2、 Value types
3、 Native types
示例:
原文地址: |
发布日期: 二, 07 八月 2007 08:37:32 GMT
计算机与 Internet |
阅读完整项
C++/CLI语言标准草案第8章语言概述节选翻译 (ZZ)
译者:jiang_hgame,justlikethewind
8.语言概述
提示:
这份规范是C++标准的一个扩展。本提示说明了该归范的必要特征.以后的章节将会祥细说明规则和例外。而这一章将以牺牲完整性的代价换来简单性和明确性。我们试图提供一个介绍以促使便于读者能编写一些初步的程序并能阅读以后的章节。
8.1起始
规范的”hello world”程序可被写成如下刑式:
int main() {
System::Console::WriteLine("hello, world");
}
C++/CLI程序的源代码被存储于一个或多个以cpp为扩展名,就像hello.cpp那样的文本文件中。使用一个命
cl hello.cpp
之后将产生一个应用文件hello.exe,运行该文件产生输出
hello, world\n
CLI库由大量名字空间组成,其中最常用的是system,该名字空间中包含一引用类Console,它提供了一组函数用于运行控制台输入输出,WriteLine是这些类中的一个,当输入一组字符串,控制台将输出该字符串并换行。(注意,我们假设该例的名字空间System已经被using语句声明)
8.2Types
值类型与句柄类型的区别在于值类型直接包含它们的数据,而句柄类型的变量存储对象的句柄。对于句柄类型来说,两个变量可能引用同一个对象。这样对其中一个变量的操作会影响到对象,从而影响到另一个变量。而对于值类型,每个变量有它们自己数据的复本,对于一个变量的操作不会影响到另一个变量。
例子
ref class Class1 {
public:
int Value;
Class1() {
Value = 0;
}
};
int main() {
int val1 = 0;
int val2 = val1;
val2 = 123;
Class1^ ref1 = gcnew Class1;
Class1^ ref2 = ref1;
ref2->Value = 123;
Console::WriteLine("Values: {0}, {1}", val1, val2);
Console::WriteLine("Refs: {0}, {1}", ref1->Value, ref2->Value);
}
从输出结果可以看出两者之间的区别
Values: 0, 123
Refs: 123, 123
对局部变量val1的赋值不会影响局部变量val2,因为两个局部变量都属于值类型(the type int ),每个值类型的局部变量都有自己的存储空间,相反的,ref2->Value = 123的赋值,影响了ref1和ref2共同引用的对象。
Console::WriteLine("Values: {0}, {1}", val1, val2);
Console::WriteLine("Refs: {0}, {1}", ref1->Value, ref2->Value);
上面几行值得做更多的注解,它们展示了某些Console::WriteLine的字符串格式化行为。实际上,它采用了可变数量的参数。第一个参量是是一个字符串,包含一定数目的{0}和{1}这样的占位符。每个占位符引用后面跟上的参量,比如{0}引用第二个参量。{1}引用第三个参量,并以次类推。在输出送到控制台前,每个占位符会被它所对应的已格式化的参数的值替换。
开发者可以通过enum和值类型的声明定义新的值类型。
实例
public enum class Color {
Red, Blue, Green
};
public value struct Point {
int x, y;
};
public interface class IBase {
void F();
};
public interface class IDerived : IBase {
void G();
};
public ref class A {
protected:
virtual void H() {
Console::WriteLine("A.H");
}
};
public ref class B : A, IDerived {
public:
void F() {
Console::WriteLine("B::F, implementation of IDerived::F");
}
void G() {
Console::WriteLine("B::G, implementation of IDerived::G");
}
virtual protected void H() override {
Console::WriteLine("B::H, override of A::H");
}
};
public delegate void MyDelegate();
上面展示了每种类型定义的实例。之后的章节将详细说明类型定义。
如上面的Color,Point和Ibase等类型,并没有在其它类型中被定义,仍然可以有一种可见性的约定,它要么是公开的(public)要么是私有的(private)。public的使用指明类型对assembly(这里并不是汇编程序的意思,在.net中指一个应用程序的概念)外是可见的。相对的,private则说明类型对assembly外不可见。类型自动默认的可见度是private。
发布日期: 二, 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++的一个超集。
lC++/CLI是一门ECMA标准[1](并且会被提交给ISO标准化委员会),而不是微软的专有语言。参与C++/CLI标准的修订的有很多组织(或公司),其中包括Edison DesignGroup,Dinkumware公司等,微软在把C++/CLI标准草案提交给ECMA组织后就放弃了对其的控制权,而是将它作为一份公开发展的标准,任何使用C++/CLI的用户都可以为它的发展提出自己的建议。
lC++/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应用)是必须的。
lGC——现在谁也不会说“往C++中加入GC就是终结了C++”这种话了。就连BjarneStroustrup也同意如果C++要被用于大型或超大型的软件开发中去,最好要有一个良好的可选的GC支持。GC与否,已经不再是个值得争论的问题,问题是,我们如何把它实现的更好——C++/CLI中的GC是目前最为强大的GC机制之一——分代垃圾收集。GC的好处是可以简化软件的开发模型,在效率并非极其关键的领域,GC可以很大程度上提高生产率。C++/CLI中的GC很重要的一点是:它正是可选的。这一点不同于JAVA或C#,对于后者,GC无处不在,对象只能分配在托管堆上。而在C++/CLI中,如果把你的对象分配在NativeHeap上,你就得到和标准C++一样的高效内存管理。如果把对象分配在ManagedHeap上,那么该对象的内存就由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,MacOSX下的Rotor(.NET的开放源代码项目),等等。
习惯了标准C++输入输出流的程序员可能要抱怨了——我们为什么要使用BCL里面的输出输出流?标准的iostream已经很好了!这里其实有一个解决方案,使用iostream的代码之所以不能“一次编译,随处运行”是因为代码要依赖于本地的二进制lib文件,而如果可以把iostream的实现重新也编译成纯MSIL代码,那么使用它的代码编译后就完全可随处运行了。目前,这是个有待商榷的方案。不过,至少当面对“总得依赖于某些平台相关的二进制代码”这种情况时,可以把平台相关的代码封装成DLL文件——对各个目标平台编译成不同的二进制版本,而程序的其它部分仍然只需一次编译即可,只要使用.NET的P/Invoke就可以对不同平台调用相应的DLL了。
l效率——作为.NET平台上的系统级编程语言,C++/CLI混合了Native和Managed两种环境。而不象C#那样只能进行托管编程。所以相对来说,C++/CLI可以具有更高的效率——前提是你愿意把效率敏感的代码用极具效率的NativeC++来写(当然,谁不愿意呢?)另外,因为标准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环境下不用作任何的改变——我曾经用NativeC++写了一个程序,其中用到了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上的对象,那么如何在ManagedHeap上创建对象呢?原来的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++语言也能保证析构函数会被调用。事实上,在异常抛出后,栈开解(stackunwind)的过程中,所有已经正确构造起来的局部对象都会被析构。这就为异常环境中资源的管理提供了一种强大而优雅的方式。
而对于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指针访问它们不会引起意外的后果。但是,refclass的内存布局是动态的,CLR可以对它的布局进行重整以做某些优化(如调整数据成员排布以更好的利用空间),从而不再是Native世界所能理解的静态结构。然而,这里最主要的问题还是:refclass底层的对象模型和Native世界的对象模型根本就不一致(比如vtbl的结构和vptr的位置),所以用Native指针来接受一个refclass实例的地址并调用它的方法简直肯定是一种灾难。由于这个原因,编译器严格禁止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平台上编程,你无可避免的要面对值类型和引用类型的微妙差别以及“疯狂”的隐式封箱——引用类型(对应于refclass)的实例是第一流的对象,继承自公共基类System::Object,拥有方法表,对象头等等。但是值类型(对应于valueclass)却极为简单,类似于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!StanLippman[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扩展的代码放在另外的头文件和源文件中。并且,尽量不要在你的Nativeclass中使用CLI的语法特性,如property,delegate,index等,尽量不要让你的Native Class继承自refClass。总之,尽量保证代码结构的清晰,你将得到最大程度上的可移植性。
小结
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)
面对C++/CLI,很多人的第一个问题自然是“什么是C++/CLI”,我个人喜欢将其看作是位于静态程序设计和动态程序设计之间的一座桥梁。C++/CLI这个名称本身就包含着一组术语——而其中最重要的术语却是最不明显的那一个。 首 先来看第一个术语“C++”,这当然指的是由Bjarne Stroustrup在Bell实验室时发明的C++编程语言。它所支持的是一种为代码执行速度和执行体所占空间所高度优化的静态对象模型。除了堆内存分 配以外,它不支持在运行时对应用程序进行任何的更改。它允许我们对底层机器进行无限的访问,但对于正在运行的程序中的活动类型、以及相关的程序基础构造, 它的访问能力却非常有限、或者根本就不可能。它是一门非常成功的编程语言,但是它却不能适应目前的Web编程环境以及相关的安全问题——这已经成为目前程 序设计中一个越来越重要的考量。 再来看第三个术语“CLI”,即通用语言基础构造(Common Language Infrastructure),这是一个支持动态组件编程模型的多层架构。在许多方面,它所表示的对象模型和C++的完全相反。在CLI中,存在一个运 行时软件层(即虚拟执行环境)运行在应用程序和底层操作系统之间,应用程序代码对底层机器的访问会受到相当严格的限制;事实上,CLI根本不允许安全环境 中的代码进行这样的访问。但另一方面,CLI却允许我们对正在运行的程序中的活动类型、以及相关的程序基础构造进行完全的访问,甚至允许我们动态构造额外 的类型和程序基础构造。这些灵活性的获得当然伴随有相当的空间(执行体所占空间)和时间(程序执行效率)代价,但是它却解决了日益增长的基于连接的计算环 境中所面临的问题和需要。 最后,再来看第二个术语,即中间的斜线“/”,它往往为人们所忽略。其表示对C++和CLI的一种绑定 (binding),它正是C++/CLI设计的焦点所在。据此,对于“什么是C++/CLI”这一问题可能的一种答案便是“它是对静态C++对象模型和 动态CLI组件模型的一种绑定”。 对于C++/CLI,一个C++程序员只需要将其添加到她[译注1]已有的编程工具箱中就可以了。要成 为一个C++/CLI程序员,你无需放弃任何已有的东西,虽然你要步入一个新的技术世界,你仍然需要学习它——但愿你能享受这一过程,至少我知道我是这样 的。由此观之,我们还可以将C++/CLI看作是一扇通往另一个世界的大门。 C++/CLI将动态的、基于组件的编程模型和ISO-C+ +集成在了一起,这种集成非常类似于我们当年在Bell实验室对使用模板的泛型编程和当时的C++所做的集成。在两种情况下,你已有的代码投资和编码经验 都将得到保留。这是我们设计C++/CLI时一个基本的需求。 通用语言基础构造(CLI)是一个多层的体系架构,它为所有CLI语言提供 了各种各样的服务。例如CLI中定义了一个通用类型系统(Common Type System,简称CTS),而各个CLI语言都提供了自己对CTS的一个映射。该类型系统由一个根基类开始被组织为一个完整的类继承体系。实际上,每一 个CLI类型都是一个类——不仅包括像integer、double这样的数值类型,而且也包括字面常量(literal constant)。每一个CLI类型(或者值)都表示一种Object(所有CLI类型的根基类),比如数值3.14159、比如字符串常量 "Homer Simpson"。 单一的根基类为运行时类型查询和代码生成(通常被称为反射)提供了支持机制[译注2],这是ISO-C++所缺乏的。我们将在今后一系列文章中详细讨论它们给CLI带来的动态编程特性。 除 此之外,CLI还支持一种被称作特性元数据(attribute metadata)的构造,它允许我们定义一些特性类,然后将其关联在CLI类型和当前正在运行的程序构造上——这有效地扩展了内建于CLI中的类型和程 序构造。这些用户定义的特性也可以通过反射机制来获得,应用程序则可以根据它们的值来进行条件逻辑判断。这也是C++/CLI为C++带来的动态组件编程 的一部分。再次强调一遍,类型反射和特性将在我们的专栏中得到深入的讨论。 |
那么,对于大家来说怎样学习C++/CLI呢?学习C++/CLI的其中一个要点便是学习底层的通用类型系统(CTS),它包括以下三种类型: 1. 多态引用类型,其用于所有的类继承。我们将在早期的一些专栏文章中讨论它们。 2. 非多态值类型,其用于实现一些类似于数值类型那样的、对运行时效率要求比较高的类型。我们将其放在引用类型之后讨论。 3. 抽象接口类型,其用于定义一组供引用类型或者值类型实现的操作。接口为多继承提供了一种别样的设计模式。我们也将有一系列专栏文章来讨论它们。 将CTS映射为一组语言内置类型对于所有的CLI语言都适用,虽然各种语言所使用的语法各不相同。这也是一门CLI语言所要面对的第一个设计层面。例如,在C#中,我们可以用以下代码来定义一个抽象基类型Shape(一些具体的几何对象将继承自它)。 public abstract class Shape {…} 而在C++/CLI中,我们用下面的代码来定义同样的类型。 public ref class Shape abstract {…}; 除了语法差异之外,两种声明的实际表示完全相同。类似地,在C#中,我们可以用下面的代码来定义一个具体类Point2D。 public struct Point2D {…} 而在C++/CLI中,我们用下面的代码来定义同样的类型。 public value class Point2D {…}; 我们对语法的选择基于如下的出发点:以一种直观的设计视角将CLI类型和ISO-C++类型紧密地集成在一起。 因此,简单地说一种语言比另一种语言更接近底层CLI并不正确。相反,每一门CLI语言都只是表达了自己对底层CLI对象模型的一种视图。 学习C++/CLI的第二个要点是学习我们选择直接提供给程序员操作的那些底层CLI元素。例如,CLI为所有语言都提供了垃圾收集服务。一门语言不能选择是否支持垃圾收集,而只能选择如何更好地提供该服务。 在CLI 中,一个引用类型的所有对象都只能被分配在CLI托管堆上。这意味着C++/CLI支持两种动态堆——本地堆(没有任何形式的自动内存回收机制),和 CLI托管堆。对于这两种动态堆,开发人员通常要用某种形式的new操作符来分配对象;如果操作成功,对象在堆中初始位置的地址将被返回。但是两者又有所 区别,这是因为CLI托管堆中对象的位置有可能在垃圾收集器的清除以及随后的压缩中被重新调整。如果一个对象的位置被重新调整,那么CLI运行时中所含的 其中一项服务会透明地更新所有引用该对象的指代品(thingee)。 这就使得我们面临着一种困难的选择:我们是将这些指代品称为指针,并且继续用指针的语法来表示它们呢?还是引入一种新的类似的语法来表示它们需要特殊的处理?我们最后决定采用后者,看下面的代码: N *pn = new N; R ^rn = gcnew R; 这 里,N表示一个本地类型,而R表示一个CLI引用类型,帽子状的符号(^)表示相关的地址是一个托管堆上的追踪句柄(tracking handle)——也就是说,对象位置的任何重新调整都会被CLI所追踪,相应的句柄也会被透明地更新。其中关键字gcnew在这里被用作与CLI托管堆 打交道的new表达式。 值类型事实上也可以位于托管堆上,虽然这并非必须。当它们作为一个引用类型的成员时,就会出现这种情况。如果我们 允许获取一个引用类型内部成员的地址,那么本地指针也是不合适的,因为这些成员的位置也需要被追踪。一种解决方法是简单地禁止该项功能。这样语言当然会变 得更加简单,但是同时语言也会变得更弱——例如我们将不能通过增长元素的地址值来遍历CLI数组,这是因为CLI数组是一个引用类型,其内的元素都位于托 管堆上。不提供这样的功能意味着CLI数组将不能适用于标准模板库(STL)中的iterator模式以及泛型算法。对于一个C++程序员来说,这是不可 接受的。 支持获取可能位于托管堆中的值类型的地址同样需要引入一种追踪指针,我们称之为追踪内部指针(tracking interior pointer)。另外,我们还支持追踪引用(tracking reference)这样的概念——它具有类似本地引用的别名语义,但是它会在必要的时候被CLI透明地更新。最后,我们还支持一种固定指针 (pinning pointer)的概念,它可以在该指针的作用范围内阻止垃圾收集器移动其所引用的对象。 这些新的符号及其表示的复杂的间接类型是在我们对托管堆反复学习和认识之后产生的。面对生存期短暂的托管堆对象,我们需要某种精巧的方式来认识和使用它们,我们相信这些额外的间接类型可以给大家很多帮助。我们将在今后的专栏文章中详细讨论它们。 我 们在此对一门CLI语言所选择的第二个设计层面表示了其对底层CLI实现模型的一层映射。选择什么样的映射取决于该编程语言定位于什么样的程序及程序员模 型。当你选择一门CLI语言进行编程的时候,你实际上也是在选择遵从一种程序员模型。我们对于C++/CLI程序员的定位是那些历练较深的系统程序员,这 些程序员通常所面对的任务是为高层的商业逻辑提供基础性的构造和关键性的应用,这时候她就必须要同时考虑系统的扩展性和性能,因此必须对底层CLI有一个 系统级的视角。 学习C++/CLI的第三个要点是学习那些非CLI本身所直接提供的功能特性。这也是每一门面向CLI的语言所要面对的设计选择,也是各种CLI语言之间相互区分的一种体现。 例 如,CLI本身并不支持多类继承(multiple class inheritance,简称MCI),而只支持多接口继承和单类继承。但Eiffel语言在设计其面向CLI的实现时就选择了支持源代码级的多类继承。 这需要一种巧妙、甚至是复杂的设计将源代码级的多类继承映射为底层CLI的单类继承模型。Eiffel语言的设计人员认为这种映射对于CLI平台上的 Eiffel程序员是一个利好的元素。 在此C++/CLI的第三个设计层面上,我们没有采用多类继承的方案。其中一个原因是我们不能说服 自己多接口继承模型有任何不够简单或者优雅的地方。我们没有足够的经验来确定哪种方案绝对的优秀,但是我的直觉告诉我多类继承(MCI)是一个死胡同。我 们在此设计层面上的主要关注点在于为那些CLI本身所欠缺的地方提供一些额外的解决方案,我们主要集中在以下三个方面: 1. 为某些CLI要求手动干预的地方提供一种自动化的解决方案,例如确定性终止化操作(deterministic finalization)和稀有资源释放。 2. 提供一些特殊的类成员函数——例如拷贝构造器和拷贝赋值操作符,以及在CLI直接支持的操作符的基础上再为一些操作符提供一些扩展支持——例如用来支持函数对象(function object)设计模式的调用操作符“()”。 3. 提供一种静态的参数化机制来支持设计适用于CLI类型的标准模板库(STL),这是因为CLI中的泛型机制在我们来看对于当代的参数化设计是不够的——虽然我们也支持它们。 以上几点在我们的系列专栏中都将有相关的讨论。特别地,我们将会详细阐释C++/CLI中的模板和泛型机制。 C+ +/CLI的第四个设计层面在于它选择了“集成”而非“替换”的策略,这是C++以及一些语言所独有的,而其他一些语言则没有这样做,例如Visual Basic采取的就是“替换”的策略。一个合法的C++程序是可以顺利通过C++/CLI编译,并且可以正常运行的。我们认为这对于我们的程序员是一项基 本的需求。 谈到C++/CLI的第四个设计层面,这究竟是什么意思呢?它表示我们对C++/CLI语言规范和ISO-C++所做的深入的 集成。例如,除了我们扩展支持集合使其也适用于统一的CLI类型系统,表达式评估的标准转换集合与重载函数的辨析都和ISO-C++的相同。当我们引入模 板和多继承机制时,我们也应用了同样的扩展策略。这些都是在语言中稍显抽象的部分,在某种程度上我们已经使它们的行为变得更加直观,免除了程序员深入算法 细节的需要。但我们仍会在系列专栏中花费笔墨关注一些主要的变化,例如对字面常量(literal)字符串的处理。 在C++/CLI未来 的版本中,我们希望为本地类型和CLI类型提供更为无缝的集成。在目前的实现中,仍然存在许多不能跨越的壁垒。例如,我们现在还不能直接在一个CLI类中 声明一个本地类的实例对象;相反,我们必须声明一个指向那个本地对象的指针,然后在CLI类的构造器/析构器对中处理对它的内存分配与释放。我们希望将来 能够透明地处理它们。类似地,如果可以方便地编写下面的代码就更好了: N^ n = gcnew N; R* pn = new R; 即将一个本地类透明地放在垃圾收集控制的托管堆中,以及将一个CLI引用类型透明地放在本地堆中,并使它们正常运行。这些是我们对于C++/CLI未来的一些设想和愿景。随着这些设想的实现,我们也会在我们的专栏中讨论它们。 |
最 后,再回答一个大家经常问到的一个问题,“我为什么要学习C++/CLI”?首要的原因是C++/CLI将会为你进入CLI所表示的动态组件编程模型领域 提供一张第一等的入口签证。如果你像我一样认为这将成为越来越重要的一种编程模型,并且如果你是一个历练较深的程序员,那么C++/CLI就是你想要的一 个语言工具。如果你不喜欢某些地方,或者发现某些东西很难表达,那么请告诉我们。我们代表着一个动态编程社区,C++/CLI也会持续不断地前进。 在C ++/CLI之前,如果我们希望或者需要在CLI所表示的动态编程领域工作,那么我们只能放弃使用C++[译注3],这意味着我们同时放弃了我们现存的代 码库和编码经验。有了C++/CLI之后,我们就拥有了一条沿着C++向上的移植路径。这是学习C++/CLI的第一个原因。 学习C++ /CLI的第二个原因在于它允许我们访问整个CLI框架类库,包括用户界面,线程,网络,XML,ADO.NET,ASP.NET,以及Web服务这个宽 广诱人的世界。另外,在即将推出的WinFX中,一个封装了整个操作系统的类库体系(包括应用程序及其执行空间[译注4])也会被收编在CLI门下。 |