Managed Extensions for C++

This article relies excessively on references to primary sources. Please improve this article by adding secondary or tertiary sources. Find sources: "Managed Extensions for C++" – news · newspapers · books · scholar · JSTOR (June 2018) (Learn how and when to remove this message)

Managed Extensions for C++ or Managed C++ is a deprecated set of language extensions for C++, including grammatical and syntactic extensions, keywords and attributes, to bring the C++ syntax and language to the .NET Framework. These extensions were created by Microsoft to allow 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.

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. The term Managed C++ and the extensions it refers to are thus deprecated and superseded by the new extensions.

History

Microsoft introduced Managed Extensions for C++ in Microsoft Visual C++ 2002 (MSVC++). Microsoft attempted to minimize the deviations between standard C++ and Managed Extensions for C++, resulting in core differences between the two being syntactically obscured. MSVC++ 2003 and 2005 also provided support for writing programs in Managed C++. In 2004, Managed Extensions for C++ was deprecated in favor of C++/CLI, a second attempt by Microsoft at supporting programming for the Common Language Infrastructure using C++.

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 standard 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) as well as 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".

Functionality

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

Managed C++ is geared towards object-oriented programming. A major difference between standard C++ and Managed C++ is that multiple inheritance is not supported, and a class managed under the CLR's garbage collector cannot inherit more than one class. This is because of a limitation of the CLR.

Key features:

• Extensible metadata: information provided to describe the structure and types of a managed component. It can be extended and reused to create software components. It is used heavily in C# and Visual Basic .NET
• Garbage collection: the CLR is fully managed by a garbage collector for memory management automated by the CLR itself, i.e. the delete operator need not be called in managed C++ code.
• Interoperability with .NET languages: code targeted for the .NET Framework produces Microsoft Intermediate Language (MSIL, similar to Java bytecode) output and thus, modules compiled and components (assemblies rather) can be reused by other program components written in another language targeting the .NET Framework, such as JScript .NET, C#, Visual Basic .NET and other 3rd party languages for .NET.
• Versioning: new methods and data members can be introduced into existing managed classes without breaking binary compatibility with existing client side software.
• Binary headers: allows reusing of precompiled metadata; any .exe, .dll, .obj or .netmodule compiled into MSIL can be referenced from a C++ source file.
• Buffer overflow protection - with the introduction of garbage collection into C++, Managed C++ is less prone to the common buffer overflow errors caused by the absence of data type checking in standard C++. The garbage collector helps to reduce (not completely though) the frequency of these errors.
• .NET framework Base Class Library - Managed C++ also has the potential to be less verbose than standard unmanaged code, since all managed function calls and inherited classes are derived from the .NET Framework Base Class Library (BCL, sometimes referred to as FCL or Framework Class Library), whose API provides TCP/IP networking capabilities, textual manipulation functions, data access (from ODBC to SQL), XML services (from XSD to XSL), GUI programming (Windows Forms), mail services (SMTP), cryptography (X509 Certificates and XML digital signatures), MSIL generation (essentially emitting instructions in MSIL), file I/O, manual manipulation of the CLR garbage collector and management information to manipulate the WMI console.

Examples

The following examples depict the use of Managed C++ as compared to standard C++:

• (Global change) Existing C++ to be ported over the CLR must be appended with the following:

// Gello.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 use 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.

// GarbageCollected.cpp

#using <mscorlib.dll>

__gc class GarbageCollected {
    int* i;
    char* g;
    float* j;
};

int main() {
    while (true) {
        GarbageCollected^ gc = gcnew GarbageCollected();
    }
    return 0;
}

The preceding code can be compiled and executed without any fear of memory leaks. Because class GarbageCollected 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:

// NotGarbageCollected.cpp

class NotGarbageCollected {
    int* i;
    char* g;
    float* j;
};

int main() {
    while (true) {
        NotGarbageCollected* g = new NotGarbageCollected();
        // ...
        delete g;
    }
    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 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 the public keyword to modify the access of the a __gc designated class.

public __gc class MyClass {
    // ...
};

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:

// MyInterface.cpp
#using <mscorlib.dll>

__gc __interface MyInterface {
    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.

Comparison with other languages

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

public __gc class First {
    int i;
};

public __gc class Second: private First { 
    int h; 
    i = h; 
}; // error

public __gc class Third: protected First {
    int h;
    i = h;
}; // error

__gc class First {};
__gc class Second {};
__gc class Third: public First, public Second {}; // will produce an error

See also

• C++/CLI

References

External links

• Managed Extensions for C++ (at MSDN)
• Article: C++ / CLI – How To Use Managed C++ DLL when Microsoft Visual C++ Redistributable is not installed?