Introduction
The Visual C ++ development team spent a lot of time listening to users' opinions. after careful consideration, the NET and C ++ decided to redesign the support for the Universal Language Runtime Library (CLR) in Visual C ++ 2005, this re-design is called "C ++/CLI", which provides a more natural syntax for using and writing CLR types. In this article, we mainly discuss New syntaxes and compare them with languages that are extremely similar to C # and managed C ++, in the text, the similarities between the chart and local C ++ are also given as appropriate.
The Universal Language Runtime Library (CLR) includes a set of specifications, which are the foundation of Microsoft. NET and the Microsoft version Implementation of CLI. C ++/CLI is designed to provide more natural C ++ support for CLI, the Visual C ++ 2005 compiler implements C ++/CLI on CLR.
After carefully studying the Visual C ++ 2005 compiler and C ++/CLI language design, you will find that they convey two important messages. First, visual C ++ positions itself in the lowest-level programming language on the CLR platform (it seems unnecessary to use other languages-including MSIL); secondly ,. NET programming should be as natural as local C ++ programming.
This article is intended for C ++ programmers, but does not want to persuade you to give up C # Or Visual Basic. NET. If you like C ++ very much and want to continue using all the functions provided by traditional C ++, and want C # programming efficiency, this article is suitable for you. In addition, this article is not an introduction to CLR or. NET Framework, but focuses on how Visual C ++ 2005 enables you to write better and more efficient code on. NET Framework.
Object Construction
CLR defines two types: Value Type and reference type. Value types are designed for efficient allocation and access. They are similar to the built-in types of C ++. You can also create your own types, this is the specific type called Bjarne Stroustrup. On the other hand, the reference type is designed to provide the features required for Object-Oriented Programming and can be used to create classes with hierarchies, such as derived classes and virtual functions. In addition, the reference type in CLR provides additional runtime features from beginning to end, such as automatic memory management-usually known as garbage collection. Meanwhile, CLR also provides precise runtime class information for the reference type and value type, which is usually called reflection.
Value types are allocated to stacks, while reference types are usually allocated to managed stacks-this is the heap managed by the CLR garbage collection mechanism. If you write assembly code in C ++, as usual, you can allocate the local C ++ type in the CRT heap. In the future, the Visual C ++ development team even allows you to allocate local C ++ types in the hosting heap. After all, garbage collection is also an attractive topic for local types.
Local C ++ allows you to select where to create a specific object. Any type can be allocated in the stack or CRT heap.
// Allocated on the stack Std: wstring stackObject;
// Allocated to the CRT heap Std: wstring * heapObject = new std: wstring; |
As shown above, where objects are allocated is independent of the type, and the initiative is in the hands of programmers. In addition, the stack and heap allocation syntax are easy to differentiate.
On the other hand, C # usually creates a value type on the stack and a reference type in the managed heap. The System. DateTime type used in the following example is declared as the value type.
// Allocated on the stack System. DateTime stackObject = new System. DateTime (2003, 1, 18 );
// Allocate it to the managed heap System. IO. MemoryStream heapObject = new System. IO. MemoryStream (); |
As shown in the preceding example, the object declaration method does not indicate that the object is allocated on the stack or in the managed heap. It depends entirely on the program writer and Runtime Library.
C ++ managed extensions-C ++ for short, can be managed in a hybrid way in local C ++ code. To comply with the C ++ standard, C ++ has been added with extensions to provide comprehensive support for CLR. Unfortunately, it is because there are too many extensions that it is very painful to use C ++ to write a lot of hosted code.
// Allocated on the stack DateTime stackObject (2003, 1, 18 );
// Allocate it to the managed heap IO: MemoryStream _ gc * heapObject = _ gc new IO: MemoryStream; |
In the view of C ++ programmers, assigning a value type on the stack looks quite normal, and the allocation method in the managed heap looks a bit strange: __gc is a keyword in hosting C ++ extensions. Interestingly, in some cases, hosting C ++ can infer what you mean, therefore, the preceding example can be rewritten without the _ gc keyword.
// Allocate it to the managed heap IO: MemoryStream * heapObject = new IO: MemoryStream; |
This looks more like the local C ++ code -- but heapObject is not a real C ++ pointer. C ++ programmers usually tend to save a constant value in the pointer, but the Garbage Collector will move the object in the memory at any time. Another disadvantage is that you cannot simply view the code to determine whether the object is distributed locally or hosted in the heap. You must know how the program writer defines a type.
C ++/CLI introduces the handle concept to distinguish CLR object reference from C ++ pointer. The C ++ pointer meaning overload is missing, and the language also lacks many ambiguities. In addition, the CLR can be more naturally supported through handles, for example, in C ++, you can directly use Operator Overloading for the reference type, because the handle can now support Operator overloading. Since C ++ prohibits the overloading of pointer operators, it is almost impossible to implement a pointer without "hosting.
// Allocated on the stack DateTime stackObject (2003, 1, 18 );
// Allocate it to the managed heap IO: MemoryStream ^ heapObject = gcnew IO: MemoryStream; |
Compared with the value type declaration, it is no different from the previous one, but for the reference type declaration, the change is very obvious. The operator ^ declares the variable as a handle to a CLR reference type. When the garbage collector moves the referenced object in the memory, it also automatically updates the handle value. In addition, they can be rebound, which allows them to point to different objects as the C ++ pointer. Another thing to note is that the gcnew operator has replaced the new operator, clearly indicating that the object is allocated in the managed heap. For hosted types, the new operator cannot be reloaded (this is not a language-based dual-off). You can only allocate the object to the CRT heap unless you provide the new operator that you have rewritten.
In short, the local C ++ pointer is already quite different from the CLR object reference.