C + +: the most powerful. Object construction of Net language

Brief introduction

The Visual C + + development team spent a lot of time listening to users ' opinions in the right. NET and C + +, after careful consideration, decided to redesign support for the common language Runtime Library (CLR) in Visual C + + 2005, a redesign called "C++/cli", which would provide a more natural syntax for using and writing CLR types. In this article, the new syntax is discussed and compared to the languages that are very similar to the two CLR platforms of C # and managed C + +, and it is also appropriate to chart the similarities to local C + + in the text.

The Common language runtime Library (CLR) includes a set of specifications, which is Microsoft. NET and is implemented by the Microsoft version of the CLI. The goal of C++/CLI language design is to provide more natural C + + support for the CLI, while the Visual C + + 2005 compiler implements C++/CLI on the CLR.

After careful study of the Visual C + + 2005 compilers and the C++/cli language design, it is found that they convey two important messages; first, Visual C + + locates itself in the lowest-level programming language on the CLR platform, (It does not seem necessary to use other languages-including MSIL); 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 + +, and want to continue to use the full functionality provided by traditional C + +, and want C # programming efficiency, then this article is suitable for you. In addition, this article is not an introduction to the CLR or the. NET Framework, but focuses on how Visual C + + 2005 enables you to write more elegant and efficient code on the. NET Framework.

Object construction

The CLR defines two types: value types and reference types. Value types are designed for efficient allocation and access, similar to the built-in types of C + +, and you can create your own type, which is the specific type that Bjarne Stroustrup refers to, and, on the other hand, reference types are designed to provide the attributes required for object-oriented programming, Can be used to create hierarchical classes, such as derived classes and virtual functions. Additionally, in the CLR, reference types provide additional run-time attributes, such as automatic memory management, which are often referred to as garbage collection. At the same time, for reference types and value types, the CLR also provides accurate Run-time class information, which is often referred to as reflection.

Value types are allocated on the stack, and reference types are typically assigned to the managed heap-a heap managed by the CLR garbage collection mechanism. If you write assembly code in C + +, as usual, you can assign local C + + types in the CRT heap, and in the future, the Visual C + + development team will even allow you to assign local C + + types in the managed heap, which, after all, is an attractive topic for local types.

Local C + + allows you to choose where to create a particular object, and any type can be assigned to the stack or the CRT heap.

Allocated on the stack
Std::wstring Stackobject;

Allocated in the CRT heap
std::wstring* heapobject = new std::wstring;
As shown above, where the object is allocated is independent of the type, the initiative is fully in the hands of the programmer. In addition, the allocation syntax for stacks and heaps is also easy to distinguish.

C #, on the other hand, typically creates a value type on the stack and creates a reference type in the managed heap. The System.DateTime type used in the following example is declared as a value type.

Allocated on the stack
System.DateTime stackobject = new System.DateTime (2003, 1, 18);

Allocated in the managed heap
System.IO.MemoryStream heapobject = new System.IO.MemoryStream ();
As the example above shows, the way the object is declared does not indicate that the object is allocated on the stack or in the managed heap, and that it depends entirely on the program writer and Run-time library.

Managed Extensions for C + +-named managed C + +, which mixes managed code in local C + + code. To follow the C + + standard, C + + is added to extend to provide full support to the CLR. Unfortunately, it is because there are so many extensions, so if you want to use C + + to write a lot of managed code, it becomes an extremely painful thing.

Allocated on the stack
DateTime Stackobject (2003, 1, 18);

Allocated in 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 very normal, the way to allocate in the managed heap looks a bit strange: __gc is a keyword in managed C + + extensions, and interestingly, in some cases managed C + + can infer what you mean, so the above example can be rewritten to take no __ GC keyword.

Allocated in the managed heap
io::memorystream* heapobject = new Io::memorystream;
This looks more like local C + + code-but Heapobject is not really a C + + pointer. C + + programmers typically tend to hold a constant value in the pointer, but the garbage collector moves the object in memory at any time. Another disadvantage is that you cannot rely solely on viewing code to determine whether an object is assigned to a local or managed heap, and you must know how a program writer defines a type.

C++/CLI introduces the concept of a handle to differentiate a CLR object reference from a C + + pointer. Without the overload of the C + + pointer, there is a lot less ambiguity in the language, and in addition, the CLR can provide more natural support through the handle, for example, you can use operator overloading directly on reference types in C + + because the handle already supports operator overloading. Because C + + disables pointer operator overloading, it is almost impossible to implement without a "managed" pointer.

Allocated on the stack
DateTime Stackobject (2003, 1, 18);

Allocated in the managed heap
io::memorystream^ heapobject = gcnew Io::memorystream;
As opposed to a value type declaration, it is no different than before, but for a reference type declaration, the change is obvious, and the operator ^ declares the variable as a handle to a CLR reference type. When the garbage collector moves the referenced object in memory, the value of the handle is also automatically updated. In addition, they are bindable, which allows them to point to different objects like C + + pointers. Another thing to note is that the operator Gcnew has replaced the operator new, clearly indicating that the object is assigned to the managed heap. For managed types, operator new is no longer overloaded (this is not a pun) and can only be assigned to the CRT heap unless you provide a new operator that you override.

In short: a local C + + pointer is already quite different from a CLR object reference.