C++ intrinsic types and __value class equivalents

[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.

[Brandon Bray [MSFT]]

Edward Diener wrote:

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 ?

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 Bray http://blogs.gotdotnet.com/branbray/
This posting is provided AS IS with no warranties, and confers no rights.

[Edward Diener]

Brandon Bray [MSFT] wrote:

Edward Diener wrote:

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 ?
It means that you can do the following:

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

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.
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 SomeMemberFunct ion(System::Int 32 *)
{ } };
....
int AnInt;
A * myA = new A();
myA -> SomeMemberFunct ion(&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.
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!

Thanks, it does.

[Brandon Bray [MSFT]]

Edward Diener wrote:

If I go the opposite way, and need to pass a __gc pointer, can I pass a
native pointer instead ?
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.

Correct.

Cheerio!

--
Brandon Bray http://blogs.gotdotnet.com/branbray/
This posting is provided AS IS with no warranties, and confers no rights.