Content deleted Content added
mNo edit summary |
|||
| (249 intermediate revisions by more than 100 users not shown) | |||
Line 1:
{{About|Microsoft's C++ language extensions deprecated in 2004|its successor|C++/CLI}}
{{Primary sources|date=June 2018}}
'''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 [[Generic programming|generics]]. These new extensions were designated [[C++/CLI]] and included in [[Microsoft Visual Studio|Microsoft Visual Studio 2005]].<ref>{{cite web|url=https://msdn.microsoft.com/en-us/library/ms379603%28VS.80%29.aspx|title=Translation Guide: Moving Your Programs from Managed Extensions for C++ to C++/CLI|date=August 2004|publisher=[[Microsoft]]|access-date=2009-11-11}}</ref> 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++.<ref name="Sutter2006">{{cite web|url=http://www.gotw.ca/publications/C++CLIRationale.pdf|last=Sutter|first=Herb|title=A Design Rationale for C/C++|page=6|url-status=live|access-date=2018-06-12|archive-date=2017-08-30|archive-url=https://web.archive.org/web/20170830063554/http://www.gotw.ca/publications/C++CLIRationale.pdf}}</ref>
== Design ==
''Managed'' refers to [[managed code]] that it is run in, or ''managed'' by, the .NET [[virtual machine]] that functions as a [[sandbox (security)|sandbox]] for enhanced security in the form of more runtime checks, such as buffer overrun checks. Additionally, applications written in Managed C++ compile to [[Common Intermediate Language|CIL]]—Common Intermediate Language—and not directly to native [[central processing unit|CPU]] instructions like standard C++ applications do.
Managed C++ code could inter-operate with any other language also targeted for the [[Common Language Runtime|CLR]] such as [[C Sharp (programming language)|C#]] and [[Visual Basic .NET]] as well as make use of features provided by the [[Common Language Runtime|CLR]] such as [[garbage collection (computer science)|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 [[Platform Invocation Services|PInvoke]] or [[Component Object Model|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 [[Common Language Runtime|CLR]]. Most notable of these is [[garbage collection (computer science)|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 [[Common Intermediate Language|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.
=== Advantages over native code ===
* Managed and unmanaged code can be mixed together in the same [[Assembly (CLI)|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 compared to fully managed code ===
* Managed C++ requires a slightly longer development time than other .NET languages that could be applied to projects that still produce the same results. The use of pointers may or may not be a requirement, because managed C++ has both value types (__value struct and __value class) and reference types (__gc struct and __gc class).
* Managed C++ fully support [[ASP.NET]] web applications, even though the development is more difficult than with other .NET languages, including some other third party languages.
* Managed C++ includes only support for templates (for interoperability with native C++) but no support for generics (for interoperability with all the other .NET languages). [[C++/CLI]] supports both templates (at compile time) and generics (at run time).
== 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:
<syntaxhighlight lang="cpp">
//hello.cpp
Line 92 ⟶ 52:
using namespace System;
int main()
{ Console::WriteLine(
return 0;
}
</syntaxhighlight>
A new preprocessor directive
<syntaxhighlight
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
<syntaxhighlight
and
<syntaxhighlight
to
* To compile code to target the CLR, a new compiler option must be introduced.
Line 116 ⟶ 77:
cl.exe hello.cpp /clr
/clr enables any code referencing the .NET Framework to be compiled as
* A class can be designated to be garbage collected via the <code>__gc</code> extension keyword.
<syntaxhighlight lang="cpp">
//gc.cpp
#using <mscorlib.dll>
__gc class gc
{ int* i;
char* g;
Line 131 ⟶ 93:
};
int main()
{ while (true)
{ gc
}
return 0;
}
</syntaxhighlight>
The preceding code can be compiled and executed without any fear of [[memory
<syntaxhighlight lang="cpp">
//nogc.cpp
class gc
{ int* i;
char* g;
Line 150 ⟶ 115:
};
int main()
{ while (true)
{ gc* _gc = new gc();
delete _gc;
Line 157 ⟶ 124:
return 0;
}
</syntaxhighlight>
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
<syntaxhighlight lang="cpp">public __gc class hey { };</syntaxhighlight>
the public keyword to modify the access of the a __gc designated class.
A __gc designated class can
* An interface can be declared with the __gc extension keyword preceding it. Such as:
<syntaxhighlight lang="cpp">
//interface.cpp
#using <mscorlib.dll>
__gc __interface ClassBase
{
void Init();
int Common();
}
</syntaxhighlight>
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.
=== Standard C++ ===
'''Disadvantages'''
* [[Native mode|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.
* C++ supports the keyword "const" and [[const correctness]]. Managed C++, like Java and C#, does not contain this feature. An alternative is to make a managed class [[Immutable object|immutable]], or restricting set accessors on public interfaces.
* C++ code is not constricted by the CLR's restrictions. For example, the CLR does not allow classes to inherit other classes privately nor protected, thus the following will produce a compiler error:
<syntaxhighlight lang="cpp">
public __gc class one { int i; };
public __gc class two: private one { int h; i = h; }; // error
public __gc class three: protected one { int h; i=h;}; // error
</syntaxhighlight>
* Managed C++ __gc classes cannot inherit from more than one class, as such the following will produce a compiler error:
<syntaxhighlight lang="cpp">
__gc class a {};
__gc class b {};
__gc class c: public a, public b {}; //will produce an error
</syntaxhighlight>
'''Advantages'''
* Managed C++ supports a greater degree of [[Reflection (computer science)|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.
=== 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.
* Java has many other development tools available for Java programmers to use, while Managed C++ is only available under [[Visual Studio .NET]].
'''Advantages'''
* Managed C++ can access the computer system on a low level interface much more easily than Java. Java programmers must use the [[Java Native Interface|JNI (Java Native Interface)]] to use low level services of the host operating system.
=== C# ===
'''Differences'''
* While C# supports pointers just as in C++, this feature is turned off by default.
'''Disadvantages'''
* Like [[Java (programming language)|Java]], C# is syntactically simpler when dealing with managed code.
* C# can achieve basically the same result as 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 codebase, 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.
== See also ==
* [[C++/CLI]]
== References
{{Reflist|2}}
== External links ==
* [https://msdn2.microsoft.com/en-us/library/Aa712867 Managed Extensions for C++ (at MSDN)]
* [https://boxedapp.com/blog/2008/07/16/c-cli-how-to-use-managed-c-dll-when-microsoft-visual-c-redistributable-is-not-installed/ Article: C++ / CLI – How To Use Managed C++ DLL when Microsoft Visual C++ Redistributable is not installed?]
{{Common Language Infrastructure}}
[[Category:C++ programming language family]]
[[Category:.NET programming languages]]
[[Category:Microsoft Visual Studio]]
| |||