471,056 Members | 1,627 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,056 software developers and data experts.

Managed, Unmanaged, Native Concepts Questions?

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

--

Feb 5 '07 #1
2 1251
Joe schrieb:
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.
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
--
For email replies, please substitute the obvious.
Feb 5 '07 #2

"Joe" <ju**@junk.coma écrit dans le message de news:
3d**************************@KNOLOGY.NET...
>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.
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
Feb 6 '07 #3

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

4 posts views Thread by Tim Menninger | last post: by
4 posts views Thread by William F. Kinsley | last post: by
6 posts views Thread by nicolas.hilaire | last post: by
reply views Thread by leo001 | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.