C++ intrinsic types and __value class equivalents

  • Thread starter Thread starter Edward Diener
  • Start date Start date
E

Edward Diener

In the doc regarding __value classes, under Primitive Types, I read:

"Generally, the C++ types and their __value class equivalents are
interchangeable in Managed Extensions."

What exactly does this mean ?

Does it mean that one can pass or return a C++ primitive to a function for
the equivalent __value class and vice-versa ?
Does this mean that one can assign the value of a C++ primitive type to the
equivalent __value class object and vice versa ?

Or what exactly is being specified here ? The rest of the topic does not
explain the quoted line above.
 
Edward said:
In the doc regarding __value classes, under Primitive Types, I read:

"Generally, the C++ types and their __value class equivalents are
interchangeable in Managed Extensions."

What exactly does this mean ?
Click to expand...

It means that you can do the following:

int x = 42;
System::Int32 y = x;
int z = y;

Basically, int and System::Int32 are exactly the same type. In fact, when
you type System::Int32 in a program, the compiler diagnostics will say "int"
instead.

The "generally" comes in when GC'ness of a type matters. This appears in two
contexts: (1) default meaning for a pointer, and (2) default meaning for an
array. The C++ type is assumed to have no GC'ness, whereas the __value class
equivalent does have GC'ness.

If a type T has GC'ness, then the declaration "T*" defaults to a __gc
pointer. If a type does not have GC'ness, then the declaration "T*" defaults
to a native pointer. To convert from a __gc pointer to a native pointer
requires pinning.

If a type T has GC'ness, then the declaration "T arr[]" defaults to a
System::Array of T. If a type T does not have GC'ness, then the declaration
"T arr[]" is a native C-style array.

Based on that summary, it should be easy to make sense of this when you read
other parts of the Managed Extenstions spec.

Hope that helps!
 
Brandon said:
It means that you can do the following:

int x = 42;
System::Int32 y = x;
int z = y;
Click to expand...

Yes, I understand this.
Basically, int and System::Int32 are exactly the same type. In fact,
when you type System::Int32 in a program, the compiler diagnostics
will say "int" instead.

The "generally" comes in when GC'ness of a type matters. This appears
in two contexts: (1) default meaning for a pointer, and (2) default
meaning for an array. The C++ type is assumed to have no GC'ness,
whereas the __value class equivalent does have GC'ness.

If a type T has GC'ness, then the declaration "T*" defaults to a __gc
pointer. If a type does not have GC'ness, then the declaration "T*"
defaults to a native pointer. To convert from a __gc pointer to a
native pointer requires pinning.
Click to expand...

If I go the opposite way, and need to pass a __gc pointer, can I pass a
native pointer instead ?

public __gc class A { public: void SomeMemberFunction(System::Int32 *)
{ } };
....
int AnInt;
A * myA = new A();
myA -> SomeMemberFunction(&AnInt);
If a type T has GC'ness, then the declaration "T arr[]" defaults to a
System::Array of T. If a type T does not have GC'ness, then the
declaration "T arr[]" is a native C-style array.
Click to expand...

OK, good. I assune there is no automatic conversion between a GC array and a
C++ array.
Based on that summary, it should be easy to make sense of this when
you read other parts of the Managed Extenstions spec.

Hope that helps!
Click to expand...

Thanks, it does.
 
Edward said:
If I go the opposite way, and need to pass a __gc pointer, can I pass a
native pointer instead ?
Click to expand...

Yes. Adding GC'ness to a pointer is fine. Only removing GC'ness requires
pinning.
OK, good. I assune there is no automatic conversion between a GC array
and a C++ array.
Click to expand...

Correct.

Cheerio!
 
Back
Top