Managed Extensions for C++

From Infogalactic: the planetary knowledge core
Jump to: navigation, search

Lua error in package.lua at line 80: module 'strict' not found. 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

  • Managed and unmanaged code can be mixed together in the same CLI assembly seamlessly. This allows the programmer to keep unmanaged code that cannot be ported over to the .NET Framework without re-writing it completely. Some ramifications of using this hybrid convention are present though.
  • Managed C++ is the only language that can contain unmanaged code and natively communicate with all other .NET languages. Managed C++ is thus very convenient for interoperability between programmers who use different languages, including those in the .NET theater and those who use standard C++.

Disadvantages compared to unmanaged code

  • Managed C++ introduces a lot of new keywords and syntactic conventions that can impair the readability of code, especially if C++ code is included directly and interacts directly with Managed C++ code in the same assembly.
  • Managed C++ is superseded by C++/CLI and thus obsolete as C++/CLI has been standardized.

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

  • Managed C++ requires a slightly longer development time than other .NET languages that could be applied to projects that still produce the same result, since the implications of pointers in C++ are still required, even in managed C++ code.
  • Managed C++ does not support ASP.NET web applications, which is a capability supported by all other languages targeting the .NET Framework, including other third party languages.
  • Managed C++ includes no support for generic programming (aka templates). C++/CLI has this support.

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++.

  • (Global change) Existing C++ to be ported over the CLR must be appended with the following:
//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.

  • To compile code to target the CLR, a new compiler option must be introduced.
   cl.exe hello.cpp /clr

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

  • A class can be designated to be garbage collected via the __gc extension keyword.
//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:

  • A __gc designated class can have a constructor declared.
  • A __gc designated class can have a destructor declared.
  • A __gc designated class cannot inherit more than one class. (This is a limitation of the CLR)
  • A __gc designated class cannot inherit another class that is not __gc designated.
  • A __gc designated class cannot be inherited by another class that is not __gc designated.
  • A __gc designated class can implement any number of __gc interfaces.
  • A __gc designated class cannot implement an unmanaged interface.
  • A __gc designated class is by default not made visible outside of its own assembly. Use
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.

  • An interface can be declared with the __gc extension keyword preceding it. Such as:
//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:

  • A __gc __interface cannot contain any data members, static members, nested class declarations and no access specifiers.
  • A __gc __interface can only inherit from another __gc __interface interface or the System::Object. Inheritance from System::Object is the default behavior.
  • A __gc __interface cannot contain any implementation (body code) of its declared function prototypes.

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

  • Running Java code requires an appropriate virtual machine, while running Managed C++ code requires an appropriate implementation of the .NET Framework.

Disadvantages

  • Java provides a documentation on the source code, while Managed C++ does not. (C++/CLI now supports this feature in Visual C++ .NET 2005 and later)
  • Java has many other development tools and solutions available for Java programmers to use, while Managed C++ is only available under Visual Studio .NET. Managed C++ applications can be compiled using the Visual C++ Toolkit 2003 however, which is provided free of charge.

Advantages

  • Managed C++ can access the computer system on a low level interface much more efficiently than Java. Java programmers must use the JNI (Java Native Interface) to utilise low level services of the host operating system.

…to C#

Differences

  • While C# supports pointers just as in C++, this feature is turned off by default.

Disadvantages

  • Like Java, C# is syntactically simpler when dealing with managed code. And C# supports the .NET Framework natively.
  • C# can achieve basically the same result when applied to the same solution as one used with Managed C++, as all syntactic and structural conventions remain strikingly similar.
  • Managed C++, though it is a strongly typed language due to its introduction into the CLR, can be prone to errors if unmanaged compiled code is introduced in the same solution, while C# is pure MSIL.

Advantages

  • C# must use the .NET Framework and provided class libraries to access the computer system on a low level.
  • Porting over applications to the .NET Framework from C or C++ is much easier to do using Managed C++.
  • The Microsoft Visual C++ .NET compiler, which compiles Managed C++ to target the .NET Framework, produces a much more matured set of instructions in its resultant assembly, thus improving performance. Performance will vary depending on the code, but in general, Managed C++ code (MSIL) is slightly faster or more efficient than code (MSIL) compiled using the C# compiler[citation needed].

…to C++

Disadvantages

  • native C++ code may be faster at runtime.
  • C++ does not require an installation of an associated compiler and managed runtime environment on the target system
  • C++ supports generic programming. Until the final release of C++/CLI however, Managed C++ programmers must revert for workarounds for using generics in their solutions.
  • C++ supports the keyword "const" and const correctness. Managed C++, like Java and C#, does not contain this feature. [Making a managed class immutable, or restricting set accessors on public interfaces enables managed code to have the same protection, to a degree.]
  • C++ code is not constricted by the CLR's restrictions. For example, the CLR does not allow classes to inherit other classes privately, thus
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

  • Managed C++ supports a greater degree of reflection than regular C++, which is generally much more convenient depending on the function of the code, or what the code is intended for.
  • Managed C++ can inter-operate with all other .NET capable languages, including other third party languages.
  • Managed C++ is garbage collected. In standard C++, memory management and allocation is the responsibility of the programmer.

See also

References

  1. Lua error in package.lua at line 80: module 'strict' not found.

External links