Introduction

When Microsoft brought out the Managed Extensions to C++ with VS.NET 7, C++ programmers accepted it with mixed reactions. While most people were happy that they could continue using C++, nearly everyone was unhappy with the ugly and twisted syntax offered by Managed C++. Microsoft obviously took the feedback it got very seriously and they decided that the MC++ syntax wasn't going to be much of a success.

On October 6th 2003, the ECMA announced the creation of a new task group to oversee development of a standard set of language extensions to create a binding between the ISO standard C++ programming language and Common Language Infrastructure (CLI). It was also made known that this new set of language extensions will be known as the C++/CLI standard, which will be supported by the VC++ compiler starting with the Whidbey release (VS.NET 2005).

Problems with the old syntax

• Ugly and twisted syntax and grammar - All those double underscores weren't exactly pleasing to the eye.
• Second class CLI support - Compared to C# and VB.NET, MC++ used contorted workarounds to provide CLI support, for e.g. it didn't have a for-each construct to enumerate .NET collections.
• Poor integration of C++ and .NET - You couldn’t use C++ features like templates on CLI types and you couldn’t use CLI features like garbage collection on C++ types.
• Confusing pointer usage - Both unmanaged C++ pointers and managed reference pointers used the same * based syntax which was quite confusing because __gc pointers were totally different in nature and behavior from unmanaged pointers.
• The MC++ compiler could not produce verifiable code

What C++/CLI gives us?

• Elegant syntax and grammar -This gave a natural feel for C++ developers writing managed code and allowed a smooth transition from unmanaged coding to managed coding. All those ugly double underscores are gone now.
• First class CLI support - CLI features like properties, garbage collection and generics are supported directly. And what's more, C++/CLI allows jus to use these features on native unmanaged classes too.
• First class C++ support - C++ features like templates and deterministic destructors work on both managed and unmanaged classes. In fact C++/CLI is the only .NET language where you can *seemingly* declare a .NET type on the stack or on the native C++ heap.
• Bridges the gap between .NET and C++ - C++ programmers won't feel like a fish out of water when they attack the BCL
• The executable generated by the C++/CLI compiler is now fully verifiable.

Hello World

				using
				namespace System;

void _tmain()
{
    Console::WriteLine("Hello World");
}

Well, that doesn't look a lot different from old syntax, except that now you don't need to add a reference to mscorlib.dll because the Whidbey compiler implicitly references it whenever you compile with /clr (which now defaults to /clr:newSyntax).

Handles

One major confusion in the old syntax was that we used the * punctuator with unmanaged pointers and with managed references. In C++/CLI Microsoft introduces the concept of handles.

				void _tmain()
{
    //The ^ punctuator represents a handle
    String^ str = "Hello World";
    Console::WriteLine(str);
}

The ^ punctuator (pronounced as cap) represents a handle to a managed object. According to the CLI specification a handle is a managed object reference. Handles are the new-syntax equivalent of __gc pointers in the MC++ syntax. Handles are not to be confused with pointers and are totally different in nature from pointers.

How handles differ from pointers?

• Pointers are denoted using the * punctuator while handles are denoted using the ^ punctuator.
• Handles are managed references to objects on the managed heap, pointers just point to a memory address.
• Pointers are stable and GC cycles do not affect them, handles might keep pointing to different memory locations based on GC and memory compactions.
• For pointers, the programmer must deleteexplicitly or else suffer a leak. For handles delete is optional.
• Handles are type-safe while pointers are most definitely not. You cannot cast a handle to a void^.
• Just as a new returns a pointer, a gcnew returns a handle.

Instantiating CLR objects

				void _tmain()
{
    String^ str = gcnew String("Hello World");
    Object^ o1 = gcnew Object();
    Console::WriteLine(str);
}

The gcnew keyword is used to instantiate CLR objects and it returns a handle to the object on the CLR heap. The good thing about gcnew is that it allows us to easily differentiate between managed and unmanaged instantiations.

Basically, the gcnew keyword and the ^ operator offer just about everything you need to access the BCL. But obviously you'd need to create and declare your own managed classes and interfaces.

Declaring types

CLR types are prefixed with an adjective that describes what sort of type it is. The following are examples of type declarations in C++/CLI :-

• CLR types
  • Reference types
    • refclass RefClass{...};
    • refstruct RefClass{...};
  • Value types
    • value class ValClass{...};
    • value struct ValClass{...};
  • Interfaces
    • interfaceclass IType{...};
    • interfacestruct IType{...};
  • Enumerations
    • enumclass Color{...};
    • enumstruct Color{...};
• Native types
  • class Native{...};
  • struct Native{...};

				using
				namespace System;

interfaceclass IDog
{
    void Bark();
};

refclass Dog : IDog
{
public:
    void Bark()
    {
        Console::WriteLine("Bow wow wow");
    }
};

void _tmain()
{
    Dog^ d = gcnew Dog();
    d->Bark();
}

There, the syntax is now so much more neater to look at than the old-syntax where the above code would have been strewn with double-underscored
?keywords like __gc and __interface.

Boxing/Unboxing

Boxing is implicit (yaay!) and type-safe. A bit-wise copy is performed and an Object is created on the CLR heap. Unboxing is explicit - just do a reinterpret_cast and then dereference.

				void _tmain()
{
    int z = 44;
    Object^ o = z; //implicit boxingint y = *reinterpret_cast<int^>(o); //unboxing

    Console::WriteLine("{0} {1} {2}",o,z,y);

    z = 66; 
    Console::WriteLine("{0} {1} {2}",o,z,y);
}

// Output// 44 44 44// 44 66 44

The Objecto is a boxed copy and does not actually refer the int value-type which is obvious from the output of the second Console::WriteLine.

When you box a value-type, the returned object remembers the original value type.

				void _tmain()
{
    int z = 44;
    float f = 33.567;

    Object^ o1 = z; 
    Object^ o2 = f; 

    Console::WriteLine(o1->GetType());
    Console::WriteLine(o2->GetType());    
}

// Output// System.Int32// System.Single

Thus you cannot try and unbox to a different type.

				void _tmain()
{
    int z = 44;
    float f = 33.567;

    Object^ o1 = z; 
    Object^ o2 = f;

    int y = *reinterpret_cast<int^>(o2);//System.InvalidCastExceptionfloat g = *reinterpret_cast<float^>(o1);
//System.InvalidCastException
}

If you do attempt to do so, you'll get a System.InvalidCastException. Talk about perfect type-safety! If you look at the IL generated, you'll see the MSIL box instruction in action. For example :-

				void Box2()
{
    float y=45;
    Object^ o1 = y;
}

gets compiled to :-

.maxstack  1
.locals (float32 V_0, object V_1)

  ldnull
  stloc.1ldc.r4     45.
  stloc.0ldloc.0
  box   [mscorlib]System.Single
  stloc.1ret

According to the MSIL docs, "The box instruction converts the ‘raw’ valueType (an unboxed value type) into an instance of type Object (of type O). This is accomplished by creating a new object and copying the data from valueType into the newly allocated object."

Further reading

• Write Faster Code with the Modern Language Features of Visual C++ 2005 [from MSDN]
• To C++ or not to C++, that is the question! [from my blog]

Conclusion

Alright, so why would anyone want to use C++/CLI when they can use C#, J# and that VB thingie for writing .NET code? Here are the four reasons I gave during my talk at DevCon 2003 in Trivandrum (Dec 2003).

• Compile existing C++ code to IL (/clr magic)
• Deterministic destruction
• Native interop support that outmatches anything other CLI languages can offer
• All those underscores in MC++ are gone ;-)

About Nishant Sivakumar

Editor Site Builder

Nish is a real nice guy living in Toronto who has been coding since 1990, when he was 13 years old. Originally from sunny Trivandrum in India, he has moved to Toronto so he can enjoy the cold winter and get to play in some snow. He works for The Code Project and handles the Dundas MFC products Ultimate Toolbox, Ultimate Grid and Ultimate TCP/IP that are sold exclusively through The Code Project Storefront. He frequents the CP discussion forums when he is not coding, reading or writing. Nish hopes to visit at least three dozen countries before his human biological mechanism stops working (euphemism used to avoid the use of the d-word here), and regrets that he hasn't ever seen snow until now (will be rectified this December). Oh btw, it must be mentioned that normally Nish is not inclined to speak about himself in the 3rd person. Nish has been a Microsoft Visual C++ MVP since October, 2002 - awfully nice of Microsoft, he thinks. He maintains an MVP tips and tricks web site - www.voidnish.com where you can find a consolidated list of his articles, writings and ideas on VC++, MFC, .NET and C++/CLI. Oh, and you might want to check out his blog on C++/CLI, MFC, .NET and a lot of other stuff - blog.voidnish.com Nish loves reading Science Fiction, P G Wodehouse and Agatha Christie, and also fancies himself to be a decent writer of sorts. He has authored a romantic comedy Summer Love and Some more Cricket as well as a programming book – Extending MFC applications with the .NET Framework. Click here to view Nishant Sivakumar's online profile.

C++的管理擴展

簡介

C++管理擴展是一組語言擴展，它幫助Microsoft Visual C++開發人員為微軟.NET編寫應用程序。

管理擴展是有用的，如果你：

• 希望提高開發人員使用C++編寫.NET應用程序的生產率
• 要分階段地將一大段代碼從非管理C++中移植到.NET平臺上
• 想從.NET Framework應用程序中使用已有的非管理C++組件。
• 想從非管理C++中使用.NET Framework組件
• 在同一應用程序中混合非管理C++代碼和.NET代碼

C++管理擴展為開發人員定位.NET Framework提供了無比的靈活性。傳統的非管理C++和管理C++代碼可以自由地混合在一個
應用程序中。用管理擴展編寫的應用程序可以利用兩種代碼的優點。使用管理擴展，現有組件可以方便地封裝到.NET組件中，
在與.NET集成的同時保留原有投資。

什么是管理擴展?
擴展允許你在C++中編寫在.NET Framework控制下運行的管理（或.NET）類。（非管理C++類運行在傳統的微軟基于Windows?
的環境中。）一個管理類是一個內置的.NET類，可以完全利用.NET Framework。

管理擴展是Visual C++開發系統的新關鍵字和屬性。它們允許開發人員決定哪些類或函數編譯為管理或非管理代碼。
這些部分然后就可以平滑地與其它部分或外部庫交互。

管理擴展也用于在C++源代碼中表示.NET類型和概念。這就允許開發人員容易地編寫.NET應用程序，而無需編寫額外代碼。

主要使用環境

• 將現有代碼平滑地移植到 .NET
  如果你在C++代碼上有大量投資，管理擴展將幫你將它們平滑地轉移到.NET平臺中。因為你可以在一個應用程序--
• 甚至是同一文件中混合管理和非管理代碼，你可以用很長時間轉移代碼，一個組件接一個組件地轉換到.NET中。
• 或你可以繼續在非管理C++中編寫組件，以利用該語言的強大功能和靈活性，只用管理擴展編寫少量的高性能的
• 封裝器（它使你的代碼可以從.NET組件中調用）。
• 從 .NET語言中訪問C++組件
  管理擴展允許你從任何.NET語言中調用C++類。你需要用擴展編寫簡單的封裝器，它將你的C++類和方法暴露為
• 管理類。封裝器是完全的管理類，可以從任何.NET語言中調用。封裝器類是作為了管理類與非管理C++類間的
• 映射層。它簡單地將方法調用直接傳遞到非管理類中。管理擴展可用于調用任何內置的動態鏈接庫（DLL）及
• 內置類。
• 從內置代碼中訪問.NET 類
  使用管理擴展，你可以創建并從C++代碼中直接調用.NET類。你可以編寫將.NET組件當作任何其它管理C++類的
• C++代碼。你可以使用.NET Framework中內置的COM調用.NET類。你使用COM還是使用管理擴展訪問.NET組件
• 要依賴于你的工程。在一些情況下，利用現有的COM支持是最好的選擇。在另一些情況下，使用管理擴展可能
• 會增加性能和開發者的生產率。
• 在同一可執行文件中的管理和內置代碼
  Visual C++編譯器能在管理和非管理上下文中自動而透明的翻譯數據、指針和指令流。這個過程是允許管理擴展
• 無縫地與非管理代碼交互的過程。開發人員能夠控制什么樣的數據和代碼可以管理。選擇每個類或函數是管理
• 還是非管理的能力為開發人員提供了更大的靈活性。一些代碼或數據類型在非管理環境中執行得要比較好。
• 另一方面，管理代碼由于如碎片收集和類庫等特性，它提高了開發人員的生產率。現有非管理代碼可以一次
• 一部分地轉化為管理代碼，因此保留了已有的投資。