C++/CLI基础：Visual C++ for .NET 3.5语言指南

下载需积分: 9 | PDF格式 | 2.85MB | 更新于2024-07-26 | 169 浏览量 | 举报

"C++/CLI 是一种用于 .NET Framework 的 C++ 扩展，它允许开发者利用 C++ 的强大功能来构建 .NET 应用程序。本书《Foundations of C++/CLI: The Visual C++ Language for .NET 3.5》由 Gordon Hogenson 编写，详细介绍了 C++/CLI 语言的基础知识，适用于 .NET Framework 3.5 版本。" 在 .NET 3.5 中，C++/CLI（之前称为 Managed C++）是一种编程语言，它结合了传统 C++ 语法与 Microsoft 的 CLI（Common Language Infrastructure）规范，使开发者能够在 .NET 平台上创建和操作托管代码。C++/CLI 提供了与 .NET Framework 类库的无缝集成，同时也保留了 C++ 的底层控制和性能优势。该书可能会涵盖以下关键知识点： 1. **托管代码与非托管代码**：解释 C++/CLI 如何在托管代码（运行于 .NET CLR 上）和非托管代码（原生 C++ 代码）之间架起桥梁，允许开发者在同一个项目中使用两者。 2. **类型系统**：介绍 CLI 的类型系统，包括值类型（Value Types）和引用类型（Reference Types），以及如何通过 `ref class` 和 `value class` 关键字声明它们。 3. **指针与智能指针**：讨论 C++/CLI 中的指针与 .NET 中的 `System::Pointer` 和 `System:: IntPtr` 类型，以及如何安全地处理内存管理。 4. **接口与多态**：阐述 C++/CLI 中的接口（Interface）实现，以及如何利用接口实现多态性，这在 .NET 中是通过虚函数和抽象类来完成的。 5. **泛型**：讲解 C++/CLI 支持的泛型概念，以及如何创建和使用泛型类和方法。 6. **CLR 与 STL**：探讨 C++/CLI 如何与 .NET Framework 中的 Collections 和 C++ 标准模板库（STL）一起工作，提供高效的数据结构和算法。 7. **异常处理**：描述 C++/CLI 中的异常处理机制，包括如何抛出和捕获 .NET 异常，以及如何与 C++ 的异常处理机制配合使用。 8. **互操作性（Interop）**：解释如何使用 C++/CLI 进行平台调用（P/Invoke）和托管-非托管互操作，以访问非 .NET 库或组件。 9. **编程实践**：可能包含关于最佳实践、设计模式和开发流程的指导，以帮助开发者编写高质量的 C++/CLI 代码。 10. **调试与性能优化**：介绍如何利用 Visual Studio 工具进行调试，以及针对 .NET 平台的性能优化技巧。这本书的作者 Gordon Hogenson 和技术审稿人 Damien Watkins 可能会提供深入的见解和实用示例，帮助读者掌握 C++/CLI 在 .NET 3.5 环境中的应用。对于希望将现有 C++ 技能应用于 .NET 开发的程序员来说，这是一个宝贵的资源。

xix

Foreword by Herb Sutter

A Design Rationale for C++/CLI

—Excerpted from “A Design Rationale for C++/CLI” by Herb Sutter. (Full text available

online at http://www.gotw.ca/publications/C++CLIRationale.pdf.)

1 Overview

A multiplicity of libraries, runtime environments, and development environments are

essential to support the range of C++ applications. This view guided the design of C++ as

early as 1987; in fact, it is older yet. Its roots are in the view of C++ as a general-purpose

language.

—B. Stroustrup (Design and Evolution of C++, Addison-Wesley Professional,

1994, p. 168)

C++/CLI was created to enable C++ use on a major runtime environment, ISO CLI (the stan-

dardized subset of .NET).

A technology like C++/CLI is essential to C++’s continued success on Windows in particu-

lar. CLI libraries are the basis for many of the new technologies on the Windows platform,

including the WinFX class library shipping with Windows Vista, which offers over 10,000 CLI

classes for everything from web service programming (Communication Foundation, WCF)

to the new 3D graphics subsystem (Presentation Foundation, WPF). Languages that do not

support CLI programming have no direct access to such libraries, and programmers who want

to use those features are forced to use one of the 20 or so other languages that do support CLI

development. Languages that support CLI include COBOL, C#, Eiffel, Java, Mercury, Perl,

Python, and others; at least two of these have standardized language-level bindings.

C++/CLI’s mission is to provide direct access for C++ programmers to use existing CLI

libraries and create new ones, with little or no performance overhead, with the minimum

amount of extra notation, and with full ISO C++ compatibility.

■FOREWORD BY HERB SUTTER

1.1 Key Goals

• Enable C++ to be a first-class language for CLI programming.

• Support important CLI features, at minimum those required for a CLS consumer and

CLS extender: CLI defines a Common Language Specification (CLS) that specifies the

subsets of CLI that a language is expected to support to be minimally functional for

consuming and/or authoring CLI libraries.

• Enable C++ to be a systems programming language on CLI: a key existing strength of

C++ is as a systems programming language, so extend this to CLI by leaving no room

for a CLI language lower than C++(besides ILASM).

• Use the fewest possible extensions.

• Require zero use of extensions to compile ISO C++ code to run on CLI: C++/CLI

requires compilers to make ISO C++ code “just work”—no source code changes or

extensions are needed to compile C++ code to execute on CLI, or to make calls

between code compiled “normally” and code compiled to CLI instructions.

• Require few or no extensions to consume existing CLI types: to use existing CLI types,

a C++ programmer can ignore nearly all C++/CLI features and typically writes a sprin-

kling of gcnew and ^. Most C++/CLI extensions are used only when authoring new

CLI types.

• Use pure conforming extensions that do not change the meaning of existing ISO C++

programs and do not conflict with ISO C++ or with C++0x evolution: this was achieved

nearly perfectly, including for macros.

• Be as orthogonal as possible.

• Observe the principle of least surprise: if feature X works on C++ types, it should also

seamlessly work on CLI types, and vice versa. This was mostly achieved, notably in

the case of templates, destructors, and other C++ features that do work seamlessly on

CLI types; for example, a CLI type can be templated and/or be used to instantiate a

template, and a CLI generic can match a template parameter.

Some unifications were left for the future; for example, a contemplated extension that the

C++/CLI design deliberately leaves room for is to use new and * to (semantically) allocate CLI

types on the C++ heap, making them directly usable with existing C++ template libraries, and

to use gcnew and ^ to (semantically) allocate C++ types on the CLI heap. Note that this would be

highly problematic if C++/CLI had not used a separate gcnew operator and ^ declarator to keep

CLI features out of the way of ISO C++.

■FOREWORD BY HERB SUTTER

xxi

1.2 Basic Design Forces

Four main programming model design forces are mentioned repeatedly in this paper:

1. It is necessary to add language support for a key feature that semantically cannot be

expressed using the rest of the language and/or must be known to the compiler.

Classes can represent almost all the concepts we need. . . . Only if the library route is

genuinely infeasible should the language extension route be followed.

—B. Stroustrup (Design and Evolution of C++, p. 181)

In particular, a feature that unavoidably requires special code generation must be known

to the compiler, and nearly all CLI features require special code generation. Many CLI features

also require semantics that cannot be expressed in C++. Libraries are unquestionably preferable

wherever possible, but either of these requirements rules out a library solution. Note that lan-

guage support remains necessary even if the language designer smoothly tries to slide in a lan-

guage feature dressed in library’s clothing (i.e., by choosing a deceptively library-like syntax). For

example, instead of

property int x; // A: C++/CLI syntax

the C++/CLI design could instead have used (among many other alternatives) a syntax like

property<int> x; // B: an alternative library-like syntax

and some people might have been mollified, either because they looked no further and thought

that it really was a library, or because they knew it wasn’t a library but were satisfied that it at least

looked like one. But this difference is entirely superficial, and nothing has really changed—it’s still

a language feature and a language extension to C++, only now a deceitful one masquerading as a

library (which is somewhere between a fib and a bald-faced lie, depending on your general sym-

pathy for magical libraries and/or grammar extensions that look like libraries).

In general, even if a feature is given library-like syntax, it is still not a true library feature when

• The name is recognized by the compiler and given special meaning (e.g., it’s in the

language grammar, or it’s a specially recognized type) and/or

• The implementation is “magical.”

Either of these make it something no user-defined library type could be. Note that, in the

case of surfacing CLI properties in the language, at least one of these must be true even if prop-

erties had been exposed using syntax like B.

xxii

■FOREWORD BY HERB SUTTER

Therefore, choosing a syntax like B would not change anything about the technical fact

of language extension, but only the political perception. This approach amounts to dressing up

a language feature with library-like syntax that pretends it’s something that it can’t be. C++’s

tradition is to avoid magic libraries and has the goal that the C++ standard library should be

implementable in C++ without compiler collusion, although it allows for some functions to be

intrinsics known to the compiler or processor. C++/CLI prefers to follow C++’s tradition, and it

uses magical types or functions only in four isolated cases: cli::array, cli::interior_ptr,

cli::pin_ptr, and cli::safe_cast. These four can be viewed as intrinsics—their implementa-

tions are provided by the CLI runtime environment and the names are recognized by the

compiler as tags for those CLI runtime facilities.

2. It is important not only to hide unnecessary differences, but also to expose essential

differences.

I try to make significant operations highly visible.

—B. Stroustrup (Design and Evolution of C++, p. 119)

First, an unnecessary distinction is one where the language adds a feature or different syntax

to make something look or be spelled differently, when the difference is not material and could

have been “papered over” in the language while still preserving correct semantics and perfor-

mance. For example, CLI reference types can never be physically allocated on the stack, but C++

stack semantics are very powerful, and there is no reason not to allow the lifetime semantics

of allocating an instance of a reference type R on the stack and leveraging C++’s automatic

destructor call semantics. C++/CLI can, and therefore should, safely paper over this difference

and allow stack-based semantics for reference type objects, thus avoiding exposing an unneces-

sary distinction. Consider this code for a reference type R:

void f()

{

R r;// OK, conceptually allocates the R on the stack

r.SomeFunc(); // OK, use value semantics

...

} // destroy r here

In the programming model, r is on the stack and has normal C++ stack-based semantics.

Physically, the compiler emits something like the following:

// f, as generated by the compiler

void f()

{

R^ r = gcnew R; // actually allocated on the CLI heap

r->SomeFunc();// actually uses indirection

...

delete r;// destroy r here (memory is reclaimed later)

}

■FOREWORD BY HERB SUTTER

xxiii

Second, it is equally important to avoid obscuring essential differences, specifically not try

to “paper over” a difference that actually matters but where the language fails to add a feature

or distinct syntax.

For example, although CLI object references are similar to pointers (e.g., they are an indirec-

tion to an object), they are nevertheless semantically not the same because they do not support

all the operations that pointers support (e.g., they do not support pointer arithmetic, stable

values, or reliable comparison). Pretending that they are the same abstraction, when they are not

and cannot be, causes much grief. One of the main flaws in the Managed Extensions design is that

it tried to reduce the number of extensions to C++ by reusing the * declarator, where T* would

implicitly mean different things depending the type of T—but three different and semantically

incompatible things, lurking together under a single syntax.

The road to unsound language design is paved with good intentions, among them the

papering over of essential differences.

3. Some extensions actively help avoid getting in the way of ISO C++ and C++0x evolution.

Any compatibility requirements imply some ugliness.

—B. Stroustrup (Design and Evolution of C++, p. 198)

A real and important benefit of extensions is that using an extension that the ISO C++ stan-

dards committee (WG21) has stated it does not like and is not interested in can be the best way

to stay out of the way of C++0x evolution, and in several cases this was done explicitly at WG21’s

direction.

For example, consider the extended for loop syntax: C++/CLI stayed with the syntax for

each( T t in c ) after consulting the WG21 evolution working group at the Sydney meeting in

March 2004 and other meetings, where EWG gave the feedback that they were interested in

such a feature but they disliked both the for each and in syntax and were highly likely never to

use it, and so directed C++/CLI to use the undesirable syntax in order to stay out of C++0x’s way.

(The liaisons noted that if in the future WG21 ever adopts a similar feature, then C++/CLI would

want to drop its syntax in favor of the WG21-adopted syntax; in general, C++/CLI aims to track

C++0x.)

Using an extension that WG21 might be interested in, or not using an extension at all but

adding to the semantics of an existing C++ construct, is liable to interfere with C++0x evolution

by accidentally constraining it. For another example, consider C++/CLI’s decision to add the

gcnew operator and the ^ declarator. . . . Consider just the compatibility issue: by adding an

operator and a declarator that are highly likely never to be used by ISO C++, C++/CLI avoids

conflict with future C++ evolution (besides making it clear that these operations have nothing

to do with the normal C++ heap). If C++/CLI had instead specified a new (gc)or new (cli)

“placement new” as its syntax for allocation on the CLI heap, that choice could have conflicted

with C++0x evolution that might want to provide additional forms of placement new. And, of

course, using a placement syntax could and would also conflict with existing code that might

already use these forms of placement new—in particular, new (gc) is already used with the

popular Boehm collector.

剩余496页未读，继续阅读

身份认证购VIP最低享 7 折!

30元优惠券

工业软件架构师

粉丝: 6

C++/CLI基础：Visual C++ for .NET 3.5语言指南

机器学习基础--Foundations_of_Machine_Learning.pdf

C++/CLI编程指南：.NET 3.5下的Visual C++语言解析

C++/CLI基础：Visual C++语言与.NET 3.5的桥梁

Foundations_of_Qt_Development-CODE

QT经典入门书籍foundations_of_qt_development-PDF书与源代码

Foundations_of_Qt_Development

Foundations_of_GTK_Development

Foundations_of_Python_Network_Programming

Foundations_of_Algorithms_2020_Labs

Foundations_of_Qt_Development src

最新资源