Managed Extensions for C++

Managed Extensions for C++ or just Managed C++ is a now deprecated Microsoft set of deviations from C++, including grammatical and syntactic extensions, keywords and attributes, to bring the C++ syntax and language to the .NET Framework. These extensions allowed C++ code to be targeted to the Common Language Runtime (CLR) in the form of managed code as well as continue to interoperate with native code. Managed C++ was not a complete standalone, or full-fledged programming language.

In 2004, the Managed C++ extensions were significantly revised to clarify and simplify syntax and expand functionality to include managed generics. These new extensions were designated C++/CLI and included in Microsoft Visual Studio 2005.[1] The term Managed C++ and the extensions it refers to are thus deprecated and superseded by the new extensions. The information provided in this article relates to the older extensions.

Design

"Managed" refers to managed code that it is run in, or managed by, the .NET virtual machine that functions as a sandbox for enhanced security in the form of more runtime checks, such as buffer overrun checks. Additionally, applications written in Managed C++ compile to CIL — Common Intermediate Language — and not directly to native CPU instructions like regular C++ applications do.

Managed C++ code could inter-operate with any other language also targeted for the CLR such as C# and Visual Basic .NET as well as make use of features provided by the CLR such as garbage collection. This means Managed C++ occupies a unique position in the gallery of .NET languages. It is the only language that can communicate directly with .NET languages (such as C#, VB.NET) and native C++. The other .NET languages can only communicate with C++ code via PInvoke or COM. But since Managed C++ can communicate directly in both managed and standard C++ contexts, it is often used as a "bridge".

Additional or amended functionality provided in Managed C++

Programs coded in Managed C++ provide additional functionality of the .NET Framework and the CLR. Most notable of these is garbage collection, which relieves the programmer of manual memory management. The garbage collector (or GC) is handled by the CLR. Memory management is executed quite quickly, but for more performance critical applications, native, unmanaged code is most likely the preferred option.

Also, C++ has evolved much over time and most software written in the language is object oriented. Managed C++ and the use of classes and class based objects remains prevalent like in Visual C++. The only major change to this in Managed C++ is that the capabilities of multiple inheritance are not supported. This is because of a limitation of the CLR. A class managed under the CLR's garbage collector cannot inherit more than one class. This is explained further in other sections.

Advantages over native code

Disadvantages compared to unmanaged code

Disadvantages to fully managed code (C#, Visual Basic, etc)

Main programmatic changes in Managed C++

The following list of changes pertain to the differences in Object Oriented Programming compared to programming with standard C++.

//hello.cpp
 
//new using directive
#using <mscorlib.dll>
 
//another using namespace directive.
using namespace System;
 
int main()
{
  Console::WriteLine("Hello, world!");
  return 0;
}

A new preprocessor directive

#using <mscorlib.dll>

is required. In addition to that, more #using directives are required to import more libraries to use more namespaces in the Base Class Library, such as

#using <System.Windows.Forms.dll>

and

using namespace System::Windows::Forms;

to utilize Windows Forms.

   cl.exe hello.cpp /clr

/clr enables any code referencing the .NET Framework to be compiled as CIL.

//gc.cpp
 
#using <mscorlib.dll>
 
 __gc class gc
{
  int* i;
  char* g;
  float* j;
};
 
int main()
{
  while(true)
  {
    gc^ _gc = gcnew gc();
  }
  return 0;
}

The preceding code can be compiled and executed without any fear of memory leaks. Because class gc is managed under the garbage collector, there is no need to call the delete operator. To achieve the same with unmanaged code, the delete keyword is required:

//nogc.cpp
 
class gc
{
  int* i;
  char* g;
  float* j;
};
 
int main()
{
  while(true)
  {
    gc* _gc = new gc();
    delete _gc;
  }
  return 0;
}

Notes:

public __gc class hey  { };

the public keyword to modify the access of the a __gc designated class.

A __gc designated class can be destroyed manually using the delete keyword, but only if the __gc designated class has a user-defined destructor.

//interface.cpp
#using <mscorlib.dll>
 
__gc __interface ClassBase
{
  void Init();
  int Common();
}

The preceding code must be compiled with /clr and /LD to produce a simple DLL file.

Notes:

Comparing Managed C++

The following contains main points and programmatic standards that differ between Managed C++ and other well known programming languages that are similar in concept.

…to Java

Differences

Disadvantages

Advantages

…to C#

Differences

Disadvantages

Advantages

…to C++

Disadvantages

public __gc class one { int i; };
public __gc class two: private one { int h; i = h; }; //error

will produce a compiler error.

[Though this is not necessarily a redeeming feature, as the point of making a class private is to prevent inheritance or access outside the class library.]

Also, __gc classes cannot inherit from more than one class, as such

__gc class a {};
__gc class b {};
__gc class c: public a, public b {}; //will produce an error

the preceding will produce a compile error.

[This is an advantage when multiple inheritance leads to problems. It could be interpreted as an advantage of managed code to prohibit poor technique. Conversely, multiple inheritance is often a very natural fit to some software modeling scenarios, and greater complexity can result in trying to avoid its use.]

Advantages

See also

References

External links