C :使用 Visual C 2005 的现代语言特色编写更快的代码(4)
添加时间:2007-09-01 原文发表:2007-08-31 人气:87 来源:vckbase.com
本文章共13664字,分9页,当前第4页,快速翻页:
| |
Interop 选项
Visual C 7.1 提供了在 Visual Studio .NET 2003 所有成员中最好的 Interop 功能。它具有实际的能力来实现现实世界的 Interop 场景。这在
Quake II 向 .NET 框架的迁移中便是例证,(具体细节参见 http://www.vertigosoftware.com/Quake2.htm ),Visual
C 2005 进一步扩展了这一功能。 在托管与本机环境中,要使用.NET Interop有四种主要途径:COM Interop 可以由
Runtime Callable Wrappers(RCW)与 COM Callable Wrappers(CCW)来实现。通用语言运行时(CLR)负责类型
封送(除非在极少的情况下使用定制的封送机制),并且这些调用的开销很大。你需要非常小心地尽量避免接口往来过于频繁,否则就会出现很严重的性能问题。你还需要保证你的那些包装一直是和其底层的组
件保持一致。也就是说,当你有大量本机 COM 代码而要使用一些简单的 Interop 应用时,COM
Interop 是非常有用处的。 第二个 Interop 的选项是使用 P/Invoke。这由使用 DLLImport 属性来完成,其中你应在方法声明处为你要引入的函数注明属性。
封送过程是依照它如何在声明处定义来处理的。然而,DLLImport 只有在当你有代码需要从DLL导出中获得函数时才是有用处的。
当你需要在本机代码中调用托管代码时,CLR 主机也是一个方法。在这种情况下,本机应用程序必须驱动所有任务的执行:建立主机,与运行库绑定,运行主机,取得适当的 AppDomain,建立调用环境,寻找需要的集合和类,并调用在目标类上的方法。在控制
发生什么以及何时发生这一角度来讲,这无疑是最完善的解决方案之一,但这也会带来令人难以想象的枯燥并需要许多自定义的代码。
第四个办法,也有可能是最简单并最可行的方法,就是使用 C 的 Interop 能力。通过设置/clr 开关,编译器会生成 MSIL 而不是本机代码。唯一被生成为本机代码的是那些无法被编译为 MSIL 的代码,此中包括带有内联汇编代码块
以及使用像(asm)和 Streaming SIMD Extensions (SSE)这样一些使用专用 CPU 固有特性的函数代码的操作。Quake II 就是使用 /clr 开关
转向.NET的。Vertigo 软件小组花费了一天的时间将原来的由C编写的游戏代码成功的转换成了C 代码,然后设置了/clr开关。很快的,他们的代码就可以毫无问题的运行在.NET框架上了。不需要添加任何多余的二进制文件而只是简单的包含了适当的头文件,托管C 和本地C 就可以在无需任何开发人员的参与
的情况下而相互调用了。编译器会处理适当代码的创建来在两种环境中自由游走。
这给C 开发人员带来了一些问题。问题之一就是现在名声名声狼籍的混合 DLL 载入问题,Visual Studio .NET 2002 和 Visual Studio
.NET 2003 的用户都受此问题的影响。如果你正在运行载入锁(loader lock)中的本机代码并且你引用了一个还没有被载入的程序集中的托管类型,CLR会非常
友善地帮你载入这一程序集。它是通过调用 LoadLibrary 来实现这一点的。当然,LoadLibrary会尝试去获得载入锁,这会使你碰到死锁问题。开发人员和产品经理一类
的人如果听说这个问题在即将推出的版本中会得到解决的话会非常高兴的。 逆风编程精品
/clr开关对 C 开发人员来说是一个极好的工具,但它也有一些缺点。像我之前提到的一样,由/clr开关产生的镜像既包含本机代码又包含托管代码,这有时会造成问题。首先,这些混合镜像并不是 CLI 兼容的(举个例子来说吧,它们无法在 Rotor 上运行)。
它们有本机的入口,而当你频繁跨越托管边界时就会带来极大的因转换而产生的开销。但最重要的是,这些本机入口的存在会对使用包括映射在内的代码集的工具带来极大的危害。为了使用映射来检查一个镜像,必须先载入代码集并执行它。只有在所有的初始化一起执行时,映射才能够检查元数据。不幸的是,映射无法正确的载入包含有本机
入口的托管代码集。 本文章更多内容:<<上一页 - 1 - 2 - 3 - 4 - 5 - 6 - 7 - 8 - 9 - 下一页>> |
 本文章所属分类: 首页
→ VC++
|
文章搜索
热门文章
推荐文章
最新文章
|