.NET包装（The .NET Wrap）

最新推荐文章于 2024-04-18 15:25:54 发布

weixin_34242819

最新推荐文章于 2024-04-18 15:25:54 发布

阅读量407

点赞数

文章标签： c/c++ c# 前端 ViewUI

原文链接：http://www.cnblogs.com/bearblog/archive/2006/05/30/413385.html

版权

MSDN Mag 2006.06.

原文出处：The .NET Wrap

翻译：Steven Xiong

翻译时间：2006年5月29日

其他MSDN文章翻译

MSDN2006年6月刊通过C++ Interop把Windows窗体集成到MFC应用程序中

MSDN2006年5月刊压力测试

NETTING C++

.NET包装（The .NET Wrap）

Stanley B. Lippman

下载这篇文章的代码：NettingC2006_06.exe（165KB）

本月，我们把专栏名称由Pure C++改为Netting C++，以便更好地反映我们把注意力集中在使用C++/CLI进行Microsoft^®.NET编程上。C++/CLI是Visual C++^®的.NET扩展，它在Visual Studio^® 2005中得到了支持。在第一个Netting C++专栏和一系列后续的文章中，我将使用Visual C++ 2005的C++/CLI语言扩展，通过一系列逐步的变换，把一个可运行的本机C++程序迁移到.NET中。程序是处理自然语言文本的文本查询语言（TQL），它是在1996年为我的C++ Primer第三版而首次开发的。它使用标准模板库（STL）和串操作，很好地验证了面向对象设计（OOD）。它应当是深入基于.NET编程的好工具。

假想的场景是：我的公司有一个运营中的本机C++应用程序，它是商业的基础，TQL。我们公司认为，它需要被扩展成Web-sensitive的，并提供对XML的支持。而且，它现在还是一个控制台应用程序（它最初是一个UNIX命令行应用程序），我们想把它改造成为具有先进的GUI界面，并为它增加用户提出的更多功能。

然而，在做所有这些很棒的东西之前，程序必须被变换成.NET程序。因为这个程序是可工作的，而且一些报告证明它工作得很好，所以我并不想改动它，至少当从改动中不能获取利益时，我不会改动它。所以，netting TQL的第一步就是把它编译成为一个.NET可执行程序。第一部分，“把本机代码编译成.NET”，就着眼于此。

尽管我描述的过程使TQL能在.NET下运行，但是它并不使用任何.NET运行时服务，也不提供与其他.NET兼容语言的互操作性。我将在第二部分“包装本机代码，在.NET下发布”中，讲述使用C++/CLI代理类包装TQL，为增加和替代现存的TQL部分程序提供必要的施展空间。

后续的专栏将关注如何把本机类型映射成由通用类型系统（CTS）支持的.NET类型，以及在程序的变换过程中，不断地检查其性能特性。我们还将查看运行时的可用类型信息，使用ildasm命令探究所有基于.NET语言编译成的通用中间语言（CIL）。

所有这些做完以后，我们将探究多线程，Web服务，与一个C# ASP.NET前端的跨语言互用性（cross-language interoperability），XML支持，以及与Windows Vista™的集成。所以，我们有活干了。（注意，本专栏的所有开发工作是通过Visual C++ IDE完成的。因此，我并没有直接使用编译器开关，但是我会在项目上做特别说明。）

把本机代码编译成.NET

我们的终极目标是把本机代码编译成一个.NET可执行程序。我从新建项目（New Project）向导中选中“Visual C++ | CLR | CLR控制台程序”作为开始，生成以下代码：

// 项目向导生成的代码

#include "stdafx.h"

using namespace System;

int main()

{

Console::WriteLine(L"Hello World");

return 0;

}

（我把它稍作了简化，移除了存储命令行参数的数组，因为我还不准备使用它。）

TQL程序有三个部分：

1．Query类层次（class hierarchy）支持用户指定的布尔查询，例如与（&&），或（||）和非（!），而不只是用户指定的文本。（图1展示了一个用户查询会话（session）的例子。）

2．UserQuery类处理交互的用户文本查询会话的所有方面。

3．TextQuery类处理实际的文本，从自文件中读取到生成一个内部的规范化结构，用于显示搜索结果。

每一个部分分别对应一组文件：Query.h和Query.cpp；UserQuery.h和UserQuery.cpp；以及TextQuery.h和TextQuery.cpp。这是六个本机C++文件，我将把它们导入项目中，理想地，我不需要对代码做重大的改变就可以编译。至少，这是C++/CLI扩展背后的主要想法之一。

当然，一种策略是一次导入所有这些文件，点击“生成”，然后看发生的事情。尽管在少量文件的情况下，这种方式也许可行，但是通常来说这会产生大量的警告和错误。我宁愿逐步地增加文件，一次一个。而且我更愿意首先编译头文件，因为通常你需要通过包含语句才能工作。除此之外，编译头文件通常比编译程序文件更为容易。

因此，我使用的过程就是这样，它基本上是完全“无痛的”，除了比较符号的（signed）和无符号的（unsigned）整数带来的两个编译器警告以外。

// 从TQL中增加存在的头文件，一次一个

// 1．没有编译错误...

#include "Query.h"

// 2．两个警告：符号/无符号比较

#include "TextQuery.h"

// 3．再一次，两个警告：符号/无符号比较

#include "UserQuery.h"

警告是从这一行程序中产生的：

if ( _paren < _current_op.size() )

这里，_current_op是一个STL栈类，函数size()返回一个无符号整数，而_paren是一个int型的计数器，它表示如"alice | ( hair & ( magical | fiery) )"的用户查询中的括号个数。编译器给出了正确的劝告：

警告C4018 : '<' : 符号/无符号不匹配

然而，从程序本身来看，_paren既不是负数，也不至于大到使比较无效，所以在这个比较中没有语义危险（semantic danger），只是可能有把int提升为unsigned的性能代价。当我们关注性能问题时，我们会确定这一情况是否真的会产生。现在，我们保留这些警告，我们的想法只是转变代码。

一旦所有的头文件编译通过以后，我一次一个地增加程序文件。产生的唯一错误是由于我没有增加预编译头支持，例如：

// 4. 增加Query.cpp

// compiler message:

// fatal error C1010: unexpected end of file while looking for

// precompiled header. Did you forget to add '#include "stdafx.h"' to your source?

事实上，这正是我所做的事情，不只是Query.cpp，TextQuery也一样：

// 5. 增加TextQuery.cpp

// a. same fatal error C1010 ... and same solution ...

// b. compiled fine ...

令人高兴的是，到处理UserQuery.cpp时，我已经被训练出来了：

// 6. 增加UserQuery.cpp和#include "stdafx.h"

要是移植有如此简单就好了！Visual C++团队做出了一个设计决定，使得引入到语言中的新关键字的潜在影响最小化，让关键字是上下文的（contextual），而不是保留关键字。只有在特定的程序上下文中，一个上下文关键字（contextual keyword）才有特定的意义。例如，在普通的程序中，sealed被当作一个普通的标识符。然而，当sealed出现在类或虚函数的声明部分时，只有在声明的上下文中时，它才被当作是一个关键字。

spaced keyword是一种特殊的上下文关键字。从字面上来说，它是由一个现存的关键字和一个上下文修饰符配对，由空格符进行分隔。一对关键字，例如“ref class”，被当作一个独立的整体，而不是两个分开的关键字。例如：

ref class Foo // spaced contextual keyword

{ ... } ^ref; // non-contextual use as identifier

在这种场合，第一个ref表明Foo是.NET引用类（reference class）的类型。第二个ref是Foo对象的标识符。帽子符号（^）表明对象类型是.NET引用类型。

既然源代码编译完成了，下一步是用程序的调用来替代刻板的Hello, World问候语，如下所示：

#include "stdafx.h"

#include "Query.h"

#include "TextQuery.h"

#include "UserQuery.h"

using namespace System;

int main()

{

TextQuery tq;

tq.build_up_text();

tq.query_text();

return 0;

}

编译和执行这个程序，它工作得很好，这相当cool。图1中的代码展示了稍做清理后的会话，红色代表用户的输入。

Visual C++的这种把本机代码转换为.NET，而不需要对源代码做重大修改的能力，既是2001年随Visual Studio .NET发布最初的托管扩展（Managed Extensions）的主要需求，也是Visual Studio 2005中替代托管扩展的C++/CLI扩展的主要需求。

包装本机代码，在.NET下发布

现在，程序已经可以在.NET下运行了，但是它的类型层次（type hierarchy）对运行时和其他语言来说都不透明，因为最初的源代码并不是在CTS中构建的。所以，下一步就是把一些托管代码集成到程序中。

我想做的是把TQL向.NET开放，但是我不想在程序员资源和时间上花费太多。首选的策略是把本机程序打包到CTS引用类的类型中。在TQL的案例中，这意味着写一个包含TextQuery对象的引用类。

所以，第一个问题是，如何在一个引用类类型中声明一个本机类对象的成员变量？答案是，必须非常小心！一个本机类的实际对象并不能直接存储在一个引用类类型中，你只能存储一个指向本机类对象的指针。所以，最初的类如下所示：

#include "TextQuery.h"

ref class TQL {

private:

// 本机对象，通过它来调用我们的程序

TextQuery *pTQuery;

};

TextQuery指针的成员变量，是本机C++的，最好随着构造函数进行初始化；同样地，在析构中释放，如下所示：

ref class TQL {

public:

// 构造函数在本机堆上创建一个TextQuery对象

// 析构函数释放对象

TQL() { pTQuery = new TextQuery; }

~TQL() { delete pTQuery; }

};

这种策略——在初始化时请求资源，在析构中释放资源——对ISO-C++程序员来说很熟悉。尽管由于.NET托管堆处理垃圾收集（garbage collection）的方式，事情会稍微复杂一些。我将下一个专栏探讨这一问题。

到目前为止，类只涉及到在托管引用类中管理本机类对象的生命期。本机应用程序现在需要的是在.NET中以某种方式公开自己的接口。开始，我只提供对TQL用户可用的公共操作（public operations）的一一映射。为了使事情简单化，只包括了两个主要的函数：

ref class TQL {

public:

// 我们希望在.NET下发布的operations

// 这些通常会被编译器内联（inline）

void build_up_text(){ pTQuery->build_up_text(); }

void query_text() { pTQuery->query_text(); }

};

在实践中，一一映射可能会太昂贵，因为每一次调用代表了.NET和本机代码间的边界跨越（boundary crossing）。但是再重复一次，我们的目标只是让代码可运行。

TQL类的定义位于名为TQL.h的头文件中，它将替代include文件列表中的TextQuery.h。现在，我将修改main函数，让它使用TQL类而不是本机TextQuery类，如下：

// 让我们的托管TQL包装者运行起来。。。

int main()

{

TQL ^tq = gcnew TQL;

tq->build_up_text();

tq->query_text();

return 0;

}

请注意gcnew关键字。当你想从.NET托管堆中分配对象时，你应当在C++/CLI中使用gcnew（但是，在本机堆中分配非CTS类型时，继续使用new）。声明

TQL ^tq

定义tq为一个指向TQL引用类对象的追踪句柄（tracking handle）。“追踪”这个词强调了引用类型位于托管堆中，因此在垃圾收集堆压缩过程中可以无错误地移动位置。追踪句柄在程序执行过程中，由运行时（runtime）自动更新。

注意，追踪句柄在调用成员函数或存取类数据成员时，使用箭头（->）成员选择操作符（member selection operator），而不是点（.）成员选择操作符。编译并运行这个程序，运行结果和第一部分描述的完全一样。

这就是包装！我拿了一个10年前的古老的本机程序，并轻松地把它移植到了.NET中。这是好的消息。不那么好的消息是，这种实现还存在一些细节的问题。我将在下一专栏中进行详细的说明。

Send your questions and comments for Stanley to purecpp@microsoft.com.

Stanley B. Lippman began working on C++ with its inventor, Bjarne Stroustrup, in 1984 at Bell Laboratories. Later, Stan worked in feature animation both at Disney and DreamWorks and served as a Software Technical Director on Fantasia 2000. He has since served as Distinguished Consultant with JPL, and an Architect with the Visual C++ team at Microsoft.

图1 TQL Query

please enter file name: alice_emma

Enter a query -- please separate each item by a space.

Terminate query (or session) with a dot( . ).

==> fiery .

fiery ( 1 ) lines match.

Location(s): [ { 3, 3 } { 3, 9 } ]

Requested query: fiery

( 3 ) like a fiery bird in flight. A beautiful fiery bird, he tells her,

Enter a query -- please separate each item by a space.

Terminate query (or session) with a dot( . ).

==> beautiful && fiery .

beautiful ( 1 ) lines match.

Location(s): [ { 3, 8 } ]

fiery ( 1 ) lines match.

Location(s): [ { 3, 3 } { 3, 9 } ]

beautiful && fiery ( 1 ) lines match.

Location(s): [ { 3, 8 } { 3, 9 } ]

Requested query: beautiful && fiery

( 3 ) like a fiery bird in flight. A beautiful fiery bird, he tells her,

Enter a query -- please separate each item by a space.

Terminate query (or session) with a dot( . ).

==> fiery || magical .

fiery ( 1 ) lines match.

Location(s): [ { 3, 3 } { 3, 9 } ]

magical ( 1 ) lines match.

Location(s): [ { 4, 1 } ]

fiery || magical ( 2 ) lines match.

Location(s): [ { 3, 3 } { 3, 9 } { 4, 1 } ]

Requested query: fiery || magical

( 3 ) like a fiery bird in flight. A beautiful fiery bird, he tells her,

( 4 ) magical but untamed. "Daddy, shush, there is no such creature,"

转载于:https://www.cnblogs.com/bearblog/archive/2006/05/30/413385.html

weixin_34242819

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
.NET包装（The .NET Wrap）

MSDN Mag 2006.06.原文出处：The .NET Wrap翻译：Steven Xiong翻译时间：2006年5月29日其他MSDN文章翻译MSDN2006年6月刊通过C++ Interop把Windows窗体集成到MFC应用程序中MSDN2006年5月刊压力测试NETTING C++.NET包装（The .NET Wr...
复制链接

扫一扫