JavaScript EditorDhtml editor     Free javascript download 



Main Page

The syntax to declare and instantiate an object of a reference class type has changed from Managed Extensions for C++ to Visual C++ 2005.

In Managed Extensions, a reference class type object is declared using the ISO-C++ pointer syntax, with an optional use of the __gc keyword to the left of the star (*). For example, here are a variety of reference class type object declarations under the Managed Extensions syntax:

В CopyCode imageCopy Code
public __gc class Form1 : public System::Windows::Forms::Form {
private:
   System::ComponentModel::Container __gc *components;
   Button __gc *button1;
   DataGrid __gc *myDataGrid;   
   DataSet __gc *myDataSet;

   void PrintValues( Array* myArr ) {
      System::Collections::IEnumerator* myEnumerator = 
         myArr->GetEnumerator();

      Array *localArray;
      myArr->Copy(myArr, localArray, myArr->Length);
   }
};

Under the new syntax, a reference class type object is declared using a new declarative token (^) referred to formally as a tracking handle and more informally as a hat. (The tracking adjective underscores the idea that a reference type sits within the CLR heap, and can therefore transparently move locations during garbage collection heap compaction. A tracking handle is transparently updated during runtime. Two analogous concepts are (a) the tracking reference (%), and (b) the interior pointer (interior_ptr<>), discussed in Value Type Semantics.

There are two primary reasons to move the declarative syntax away from a reuse of the ISO-C++ pointer syntax:

The use of the __gc modifier on a tracking handle is unnecessary and is not supported. The use of the object itself is not changed; it still accesses members through the pointer member selection operator (->). For example, here is the above Managed Extensions text translated into the new syntax:

В CopyCode imageCopy Code
public ref class Form1: public System::Windows::Forms::Form {
private:
   System::ComponentModel::Container^ components;
   Button^ button1;
   DataGrid^ myDataGrid;
   DataSet^ myDataSet;

   void PrintValues( Array^ myArr ) {
      System::Collections::IEnumerator^ myEnumerator =
         myArr->GetEnumerator();

      Array ^localArray;
      myArr->Copy(myArr, localArray, myArr->Length);   }
};

Dynamic Allocation of an Object on the CLR Heap

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,

В CopyCode imageCopy 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:

В CopyCode imageCopy 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:

В CopyCode imageCopy 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.

В CopyCode imageCopy 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 );
}

A Tracking Reference to No Object

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:

В CopyCode imageCopy 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:

В CopyCode imageCopy 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:

В CopyCode imageCopy 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:

В CopyCode imageCopy 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:

В CopyCode imageCopy 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:

В CopyCode imageCopy 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.)

В CopyCode imageCopy 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.

В CopyCode imageCopy 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:

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

An invocation with nullptr literal, such as the following,

В CopyCode imageCopy 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):

В CopyCode imageCopy 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.

See Also

Reference

Classes and Structs (Managed)
^ (Handle to Object on Managed Heap)
nullptr

Concepts

The Managed Types



JavaScript EditorDhtml editor     Free javascript download 
Bitcoin Gambling - The Original Crypto Dice Game . Seo tools saltlakeseo search engine rank tracking software.