MSIL from C++ with /clr option but no __gc

  • Thread starter Thread starter NigelW
  • Start date Start date
N

NigelW

Clarification needed please.

If I compile a C++ program with the /clr option inpsection
of the resulting assembly with ILDASM shows MSIL even for
methods in classes for which I have not specified garbage
collection with __gc.

Am I correct in thinking there is really two kinds of
managed (i.e. MSIL) code from C++, that which uses garbage
collection and that which does not?
 
NigelW said:
Clarification needed please.

If I compile a C++ program with the /clr option inpsection
of the resulting assembly with ILDASM shows MSIL even for
methods in classes for which I have not specified garbage
collection with __gc.

Am I correct in thinking there is really two kinds of
managed (i.e. MSIL) code from C++, that which uses garbage
collection and that which does not?
Click to expand...

No, you are incorrect. Using the /clr option will compile almost all C++
code to MSIL whether the types involved are __gc, __value, or __nogc ( the
default ). There are only a few C++ constructs which will not be compiled to
MSIL and these are outlined in the MC++ language specification, section 24.1
.. Everything else, when /clr is used, is compiled to MSIL whether managed or
unmanaged.
 
-----Original Message-----


No, you are incorrect. Using the /clr option will compile almost all C++
code to MSIL whether the types involved are __gc, __value, or __nogc ( the
default ). There are only a few C++ constructs which will not be compiled to
MSIL and these are outlined in the MC++ language specification, section 24.1
.. Everything else, when /clr is used, is compiled to MSIL whether managed or
unmanaged.


.
Thank you for confirming nearly all C++ gets compiled to
Click to expand...
MSIL when the /clr option is used. So I know see MSIL can
be used in managed or unmanaged ways (I was confused
because the documentation always equates unmanaged to
native).

In Section 24.1 of the C++ language spec. it says method
calls through pointers, including to virtual functions
through the vtable, cannot be compiled to MSIL. However,
examination of the MSIL for several methods calling
virtual functions shows that virtual methods can in fact
be used without preventing compilation to MSIL. Can you
shed any light on this discrepancy?

Thank you
 
MSIL when the /clr option is used. So I know see MSIL can
be used in managed or unmanaged ways (I was confused
because the documentation always equates unmanaged to
native).

In Section 24.1 of the C++ language spec. it says method
calls through pointers, including to virtual functions
through the vtable, cannot be compiled to MSIL. However,
examination of the MSIL for several methods calling
virtual functions shows that virtual methods can in fact
be used without preventing compilation to MSIL. Can you
shed any light on this discrepancy?
Click to expand...

Virtual methods are compiled to MSIL. It is when you use C++'s ability to
call object methods through method pointers that the compiler can not
compile the function in which you make such a call to MSIL. A C++ method
pointer looks like:

returnType SomeObject.*SomePointer(parameterTypes) =
&SomeObject::SomeMethod;

and is invoked via either:

returnType rt = aSomeObject.*SomePointer(parameters);

or

returnType rt = aPointerToSomeObject->*SomePointer(parameters);

This is what 24.1 is talking about when it says that "method calls through
pointers, including to virtual functions
through the vtable, cannot be compiled to MSIL."
 
Back
Top