Managed, Unmanaged, Native Concepts Questions?

  • Thread starter Thread starter Joe
  • Start date Start date
J

Joe

I am trying to get a good understanding of these concepts and how they apply
to code and classes (possibly different). As well as MSIL and Native Code
(x86 assembly).

To facilitate discussion consider the following code.

//////////////////////////////////////////////////
// compiled with /clr

ref class A {
//code and members
};


class B{
//code and members
};

#pragma unmanaged

class C{
//code and members
};

//////////////////////////////////////////////

Are the following comments correct?

Class A
1. Class A is a managed type (because it is gc)
2. Class A code is MSIL executed by the CLR
3. Class A is dynamically allocated with gcnew on the CLR heap (thus garbage
collected);

Class B
1. Class B is a native type (because it does not use new language
constructs)
2. Class B is a unmanaged type (because it is not gc)
3. Class B code is MSIL executed by the CLR
4. Class B is dynamically allocated with "new" on the regular C++ heap (not
gc).

Class C
1. Class C is a native type (because it does not use new language
constructs)
2. Class C is a unmanaged type (because it is not gc)
3. Class C code is X86 assembly code ran directly on the processor
4. Class C code is dynamically allocated the "new" on the regular C++ heap
(not gc).


Note the only difference in B and C is the type of code generated.
Note that Class B is unmanaged even though it occurs because the #pragma
unmanaged statement. That's a bit confusing. Do I have that concept correct?

It you have any other permutations of logic that would be helpful, I would
appreciate them.

Thanks Joe

--
 
Joe said:
I am trying to get a good understanding of these concepts and how they apply
to code and classes (possibly different). As well as MSIL and Native Code
(x86 assembly).

To facilitate discussion consider the following code.

//////////////////////////////////////////////////
// compiled with /clr

ref class A {
//code and members
};


class B{
//code and members
};

#pragma unmanaged

class C{
//code and members
};

//////////////////////////////////////////////

Are the following comments correct?

Class A
1. Class A is a managed type (because it is gc)
2. Class A code is MSIL executed by the CLR
3. Class A is dynamically allocated with gcnew on the CLR heap (thus garbage
collected);

Class B
1. Class B is a native type (because it does not use new language
constructs)
2. Class B is a unmanaged type (because it is not gc)
3. Class B code is MSIL executed by the CLR
4. Class B is dynamically allocated with "new" on the regular C++ heap (not
gc).

Class C
1. Class C is a native type (because it does not use new language
constructs)
2. Class C is a unmanaged type (because it is not gc)
3. Class C code is X86 assembly code ran directly on the processor
4. Class C code is dynamically allocated the "new" on the regular C++ heap
(not gc).


Note the only difference in B and C is the type of code generated.
Note that Class B is unmanaged even though it occurs because the #pragma
unmanaged statement. That's a bit confusing. Do I have that concept correct?

It you have any other permutations of logic that would be helpful, I would
appreciate them.
Click to expand...
As far as I know, even class A can be declared as a "normal" variable, i.e.
"A MyVar;", at which point normal C++ life cycle management takes place, even
if the actual object exists on the managed heap and the release of the raw
memory will be handled by the garbage collector. IMHO one of the great
advantages C++/CLI has over other .NET languages.

Lots of Greetings!
Volker
 
Joe said:
I am trying to get a good understanding of these concepts and how they
apply to code and classes (possibly different). As well as MSIL and Native
Code (x86 assembly).

To facilitate discussion consider the following code.

//////////////////////////////////////////////////
// compiled with /clr

ref class A {
//code and members
};


class B{
//code and members
};

#pragma unmanaged

class C{
//code and members
};

//////////////////////////////////////////////

Are the following comments correct?

Class A
1. Class A is a managed type (because it is gc)
2. Class A code is MSIL executed by the CLR
3. Class A is dynamically allocated with gcnew on the CLR heap (thus
garbage collected);

Class B
1. Class B is a native type (because it does not use new language
constructs)
2. Class B is a unmanaged type (because it is not gc)
3. Class B code is MSIL executed by the CLR
4. Class B is dynamically allocated with "new" on the regular C++ heap
(not gc).

Class C
1. Class C is a native type (because it does not use new language
constructs)
2. Class C is a unmanaged type (because it is not gc)
3. Class C code is X86 assembly code ran directly on the processor
4. Class C code is dynamically allocated the "new" on the regular C++ heap
(not gc).


Note the only difference in B and C is the type of code generated.
Note that Class B is unmanaged even though it occurs because the #pragma
unmanaged statement. That's a bit confusing. Do I have that concept
correct?

It you have any other permutations of logic that would be helpful, I would
appreciate them.
Click to expand...

You're basically correct, but with a few precisions :
- B and C objects (native types) can also be allocated directly on the stack
or within aonther object. They do not necessraly are on the native heap.
- A objects can also be declared "on the stack" using the "A myobject;"
syntax. However, in this case, the object is really, physically, allocated
on the manegd heap. However, the compiler injects the necessary code so that
your code has the same semantic as with native types : ie, the object is
destroyed - that is, it's destructor is called - when the variable
"myobject" goes out of scope.

Arnaud
MVP - VC
 
Back
Top