In Managed Extensions, the existence of two new expressions to allocate between the native and managed heap was largely transparent. In nearly all instances, the compiler is able by context to correctly determine whether the native or managed heap is intended. For example,

В	Copy Code
Button *button1 = new Button; // OK: managed heap int *pi1 = new int; // OK: native heap Int32 *pi2 = new Int32; // OK: managed heap

In cases in which the contextual heap allocation is not the intended instance, one could direct the compiler with either the __gc or __nogc keyword. In the new syntax, the separate nature of the two new expressions is made explicit with the introduction of the gcnew keyword. For example, the above three declarations look as follows in the new syntax:

В	Copy Code
Button^ button1 = gcnew Button; // OK: managed heap int * pi1 = new int; // OK: native heap Int32^ pi2 = gcnew Int32; // OK: managed heap

Here is the Managed Extensions initialization of the Form1 members declared in the previous section:

В	Copy Code
void InitializeComponent() { components = new System::ComponentModel::Container(); button1 = new System::Windows::Forms::Button(); myDataGrid = new DataGrid(); button1->Click += new System::EventHandler(this, &Form1::button1_Click); }

Here is the same initialization recast to the new syntax. Note that the hat is not required for the reference type when it is the target of a gcnew expression.

В	Copy Code
void InitializeComponent() { components = gcnew System::ComponentModel::Container; button1 = gcnew System::Windows::Forms::Button; myDataGrid = gcnew DataGrid; button1->Click += gcnew System::EventHandler( this, &Form1::button1_Click ); }

In the new syntax, 0 no longer represents a null address but is simply treated as an integer, the same as 1, 10, or 100, and so we needed to introduce a special token to represent a null value for a tracking reference. For example, in Managed Extensions, we initialize a reference type to address no object as follows:

В	Copy Code
// OK: we set obj to refer to no object Object * obj = 0; // Error: no implicit boxing … Object * obj2 = 1;

In the new syntax, any initialization or assignment of a value type to an Object results in an implicit boxing of that value type. In the new syntax, both obj and obj2 are initialized to addressed boxed Int32 objects holding, respectively, the values 0 and 1. For example:

В	Copy Code
// causes the implicit boxing of both 0 and 1 Object ^ obj = 0; Object ^ obj2 = 1;

Therefore, in order to allow the explicit initialization, assignment, and comparison of a tracking handle to null, we introduced a new keyword, nullptr. And so the correct revision of the original example looks as follows:

В	Copy Code
// OK: we set obj to refer to no object Object ^ obj = nullptr; // OK: we initialize obj2 to a Int32^ Object ^ obj2 = 1;

This complicates somewhat the porting of existing code into the new syntax. For example, consider the following value class declaration:

В	Copy Code
__value struct Holder { Holder( Continuation* c, Sexpr* v ) { cont = c; value = v; args = 0; env = 0; } private: Continuation* cont; Sexpr * value; Environment* env; Sexpr * args __gc []; };

where both args and env are CLR reference types. The initialization of these two members to 0 in the constructor cannot remain unchanged in the transition to the new syntax. Rather, they must be changed to nullptr:

В	Copy Code
value struct Holder { Holder( Continuation^ c, Sexpr^ v ) { cont = c; value = v; args = nullptr; env = nullptr; } private: Continuation^ cont; Sexpr^ value; Environment^ env; array<Sexpr^>^ args; };

Similarly, tests against those members comparing them to 0 must also be changed to compare the members to nullptr . Here is the Managed Extensions syntax:

В	Copy Code
Sexpr * Loop (Sexpr* input) { value = 0; Holder holder = Interpret(this, input, env); while (holder.cont != 0) { if (holder.env != 0) { holder=Interpret(holder.cont,holder.value,holder.env); } else if (holder.args != 0) { holder = holder.value->closure()-> apply(holder.cont,holder.args); } } return value; }

and here is the revision, turning each 0 instance into a nullptr. (The translation tool helps in this transformation, automating many if not all of the occurrences, including use of the NULL macro.)

В	Copy Code
Sexpr ^ Loop (Sexpr^ input) { value = nullptr; Holder holder = Interpret(this, input, env); while ( holder.cont != nullptr ) { if ( holder.env != nullptr ) { holder=Interpret(holder.cont,holder.value,holder.env); } else if (holder.args != nullptr ) { holder = holder.value->closure()-> apply(holder.cont,holder.args); } } return value; }

The nullptr is converted into any pointer or tracking handle type but is not promoted to an integral type. For example, in the following set of initializations, the nullptr is only legal as an initial value to the first two.

В	Copy Code
// OK: we set obj and pstr to refer to no object Object^ obj = nullptr; char* pstr = nullptr; // 0 would also work here … // Error: no conversion of nullptr to 0 … int ival = nullptr;

Similarly, given an overloaded set of methods such as the following:

В	Copy Code
void f( Object^ ); // (1) void f( char* ); // (2) void f( int ); // (3)

An invocation with nullptr literal, such as the following,

В	Copy Code
// Error: ambiguous: matches (1) and (2) f( nullptr );

is ambiguous because the nullptr matches both a tracking handle and a pointer and there is no preference given to one type over the other. (This requires an explicit cast in order to disambiguate.)

An invocation with 0 exactly matches instance (3):

В	Copy Code
// OK: matches (3) f( 0 );

because a 0 is of type integer. Were f(int) not present, the call would unambiguously match f(char*) through a standard conversion. The matching rules gives precedence of an exact match over a standard conversion. In the absence of an exact match, a standard conversion is given precedence over an implicit boxing of a value type. This is why there is no ambiguity.

Reference

Concepts