Click here to Skip to main content
11,706,455 members (37,597 online)
Click here to Skip to main content

A first look at C++/CLI

, 27 Apr 2004 435.6K 128
Rate this:
Please Sign up or sign in to vote.
A brief look at the new C++/CLI syntax and how it improves over the old MC++ syntax

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 delete explicitly 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
      • ref class RefClass{...};
      • ref struct RefClass{...};
    • Value types
      • value class ValClass{...};
      • value struct ValClass{...};
    • Interfaces
      • interface class IType{...};
      • interface struct IType{...};
    • Enumerations
      • enum class Color{...};
      • enum struct Color{...};
  • Native types
    • class Native{...};
    • struct Native{...};
using namespace System;

interface class IDog
{
    void Bark();
};

ref class 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 boxing

    int 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 Object o 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.InvalidCastException
    float 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.1
  ldc.r4     45.
  stloc.0
  ldloc.0
  box   [mscorlib]System.Single
  stloc.1
  ret

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

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 Wink | ;-)

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here

Share

About the Author

Nish Nishant
United States United States
Nish Nishant is a Software Architect/Consultant based out of Columbus, Ohio. He has over 15 years of software industry experience in various roles including Lead Software Architect, Principal Software Engineer, and Product Manager. Nish is a recipient of the annual Microsoft Visual C++ MVP Award since 2002 (13 consecutive awards as of 2014).

Nish is an industry acknowledged expert in the Microsoft technology stack. He authored
C++/CLI in Action for Manning Publications in 2005, and had previously co-authored
Extending MFC Applications with the .NET Framework for Addison Wesley in 2003. In addition, he has over 140 published technology articles on CodeProject.com and another 250+ blog articles on his
WordPress blog. Nish is vastly experienced in team management, mentoring teams, and directing all stages of software development.

Contact Nish : You can reach Nish on his google email id voidnish.

Website and Blog

You may also be interested in...

Comments and Discussions

 
QuestionCan we have a Managed object of type value on the Managed heap ? Pin
faraz412918-Jan-12 14:23
memberfaraz412918-Jan-12 14:23 
Question[My vote of 1] WOW NICE COPY AND PASTE ARTICLE Pin
a ahole26-Jun-11 10:59
membera ahole26-Jun-11 10:59 
GeneralMy vote of 5 Pin
Sharan Basappa7-Sep-10 4:51
memberSharan Basappa7-Sep-10 4:51 
GeneralC++ / CLI for a big project Pin
N a v a n e e t h9-Nov-08 21:23
memberN a v a n e e t h9-Nov-08 21:23 
GeneralCongratulations! Pin
Indivara10-Aug-08 21:53
memberIndivara10-Aug-08 21:53 
GeneralUsing C# in Managed C++/CLI Pin
Allston9-Feb-08 11:16
memberAllston9-Feb-08 11:16 
AnswerRe: Using C# in Managed C++/CLI Pin
Ri Qen-Sin18-Feb-08 4:41
memberRi Qen-Sin18-Feb-08 4:41 
Generalreturning CLI byte array Pin
mhelinx093-Jul-07 14:56
membermhelinx093-Jul-07 14:56 
QuestionHow to convert a managed Handle to unmanaged HANDLE Pin
kosmas17-May-07 4:24
memberkosmas17-May-07 4:24 
AnswerRe: How to convert a managed Handle to unmanaged HANDLE Pin
Portatofe2-Oct-08 8:31
memberPortatofe2-Oct-08 8:31 
GeneralSTL.NET Pin
Ed K30-Oct-06 9:49
memberEd K30-Oct-06 9:49 
GeneralRe: STL.NET Pin
Nishant Sivakumar9-Nov-06 15:14
editorNishant Sivakumar9-Nov-06 15:14 
GeneralUsing Static cast instead of reinterpret cast Pin
Sarath.22-Sep-06 5:44
memberSarath.22-Sep-06 5:44 
GeneralRe: Using Static cast instead of reinterpret cast Pin
Nishant Sivakumar22-Sep-06 5:50
staffNishant Sivakumar22-Sep-06 5:50 
GeneralDictionary Conversion Pin
pankajmishra10-Sep-06 21:59
memberpankajmishra10-Sep-06 21:59 
QuestionHow to handle the pointers Pin
Koundinya10-Aug-06 22:22
memberKoundinya10-Aug-06 22:22 
AnswerRe: How to handle the pointers Pin
Tata Taufik31-Aug-06 5:07
memberTata Taufik31-Aug-06 5:07 
GeneralC# or C++/CLI Pin
kerbydude18-Mar-06 9:03
memberkerbydude18-Mar-06 9:03 
GeneralRe: C# or C++/CLI Pin
Nishant Sivakumar18-Mar-06 9:29
staffNishant Sivakumar18-Mar-06 9:29 
GeneralRe: C# or C++/CLI Pin
kerbydude18-Mar-06 11:08
memberkerbydude18-Mar-06 11:08 
GeneralCreating an managed class in an umanaged class Pin
d00_ape14-Mar-06 23:37
memberd00_ape14-Mar-06 23:37 
General... wrong compiler error message... Pin
d00_ape14-Mar-06 23:45
memberd00_ape14-Mar-06 23:45 
GeneralPorting checklist Pin
Tom Archer - MSFT5-Nov-05 16:23
memberTom Archer - MSFT5-Nov-05 16:23 
GeneralManaged resources Pin
core.cure21-Sep-05 5:53
membercore.cure21-Sep-05 5:53 
Generaltrrui Pin
yaniv_s130-May-05 7:42
memberyaniv_s130-May-05 7:42 
GeneralNice to see MS is beginning to think out the box Pin
Dan Madden6-May-05 12:32
memberDan Madden6-May-05 12:32 
Generaltemplates vs. generics Pin
J. R. Roberts17-Dec-04 7:17
memberJ. R. Roberts17-Dec-04 7:17 
GeneralDialogResult Pin
Majid Shahabfar23-Nov-04 9:17
memberMajid Shahabfar23-Nov-04 9:17 
GeneralRe: DialogResult Pin
jus19928-Nov-06 0:18
memberjus19928-Nov-06 0:18 
GeneralP/Invoke or MC++ wrapper Pin
Imtiaz Murtaza19-Nov-04 23:25
memberImtiaz Murtaza19-Nov-04 23:25 
GeneralRe: P/Invoke or MC++ wrapper Pin
Nishant S20-Nov-04 0:51
staffNishant S20-Nov-04 0:51 
GeneralString^ str to string str in C++ Pin
Majid Shahabfar24-Aug-04 6:35
memberMajid Shahabfar24-Aug-04 6:35 
GeneralRe: String^ str to string str in C++ Pin
Nishant S24-Aug-04 7:56
staffNishant S24-Aug-04 7:56 
GeneralRe: String^ str to string str in C++ Pin
Majid Shahabfar24-Aug-04 8:28
memberMajid Shahabfar24-Aug-04 8:28 
GeneralRe: String^ str to string str in C++ Pin
Majid Shahabfar25-Aug-04 5:26
memberMajid Shahabfar25-Aug-04 5:26 
GeneralRe: String^ str to string str in C++ Pin
Nishant S25-Aug-04 16:37
staffNishant S25-Aug-04 16:37 
GeneralRe: String^ str to string str in C++ Pin
Majid Shahabfar25-Aug-04 22:11
memberMajid Shahabfar25-Aug-04 22:11 
GeneralRe: String^ str to string str in C++ Pin
Nishant S25-Aug-04 22:52
staffNishant S25-Aug-04 22:52 
GeneralCalling C++/CLI from c# - ref arguments Pin
leicesters24-Aug-04 4:50
memberleicesters24-Aug-04 4:50 
GeneralRe: Calling C++/CLI from c# - ref arguments Pin
Nishant S24-Aug-04 8:04
staffNishant S24-Aug-04 8:04 
GeneralC# or C++/CLI This is the problem Pin
Majid Shahabfar6-Aug-04 8:54
memberMajid Shahabfar6-Aug-04 8:54 
GeneralRe: C# or C++/CLI This is the problem Pin
Nishant S6-Aug-04 9:01
staffNishant S6-Aug-04 9:01 
GeneralInteresting how all the __gc .NET code is the real &quot;legacy code&quot;! Pin
Don Clugston11-May-04 14:45
memberDon Clugston11-May-04 14:45 
GeneralRe: Interesting how all the __gc .NET code is the real &quot;legacy code&quot;! Pin
Yuancai (Charlie) Ye18-May-04 2:59
memberYuancai (Charlie) Ye18-May-04 2:59 
GeneralRe: Interesting how all the __gc .NET code is the real &quot;legacy code&quot;! Pin
tong_du19-May-04 5:32
membertong_du19-May-04 5:32 
GeneralRe: Interesting how all the __gc .NET code is the real &quot;legacy code&quot;! Pin
Miguel Lopes19-May-04 5:17
memberMiguel Lopes19-May-04 5:17 
GeneralGood read Pin
Douglas Troy6-May-04 5:29
memberDouglas Troy6-May-04 5:29 
GeneralJagged Arrays Pin
PaulW4-May-04 11:28
memberPaulW4-May-04 11:28 
GeneralRe: Jagged Arrays Pin
Nishant S4-May-04 17:28
staffNishant S4-May-04 17:28 
GeneralRe: Jagged Arrays Pin
Nishant S5-May-04 3:38
staffNishant S5-May-04 3:38 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Terms of Use | Mobile
Web03 | 2.8.150819.1 | Last Updated 28 Apr 2004
Article Copyright 2004 by Nish Nishant
Everything else Copyright © CodeProject, 1999-2015
Layout: fixed | fluid