Subtle diffs between C++IJW, unmanaged, __nogc, etc

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

J

Compiling a straight C++ module under VC++ 7 would seem to autogen an
'IJW' type .NET module, even if the module has standard VC++ syntax.

I'm assuming that the 'unmanaged' flag would have no further affect on
this code. Nor would __nogc. Correct? Or are there subtle further
differences?

Are there recommended references that sort this type of thing out in
precise detail?
 
Hi J,
Compiling a straight C++ module under VC++ 7 would seem to autogen an
'IJW' type .NET module, even if the module has standard VC++ syntax.
Click to expand...

Only if you compile with /clr. Unless you enable that, the compiler will
produce straight x86 machine code, no .NET anywhere, just as with VC 6.
I'm assuming that the 'unmanaged' flag would have no further affect on
this code. Nor would __nogc. Correct? Or are there subtle further
differences?
Click to expand...

What unmanaged flag? you mean #pragma unmanaged? That is only useful to
force methods to be compiled as x86 code in a module compiled with /clr.
Once you enable /clr, all methods (regardless of whether they are global
methods or class members) get compiled as MSIL (but classes themselves
remain unmanaged types), unless they use a few special idioms (variable arg
methods, inline asm code, etc.) that force the compiler to generate them as
unmanaged code anyway, or you use #pragma unmanaged on them

The __nogc thing, whether it causes semantic changes, depends a lot on what
context you are using it, but, for the most part, in your example it should
cause non.
 
Hi J,


Only if you compile with /clr. Unless you enable that, the compiler will
produce straight x86 machine code, no .NET anywhere, just as with VC 6.
Click to expand...

Yes, that's what I meant.
What unmanaged flag? you mean #pragma unmanaged? That is only useful to
force methods to be compiled as x86 code in a module compiled with /clr.
Click to expand...

Yes, #pragma. I should have been more specific. It brings up an
interesting point though. I'm trying to fit code together between
managed, unmanaged and a legacy DLL (unmanaged, of course).
It never occurred to me to compile the middle level without the
#pragma unmanaged flag, as I thought it would be a more reliable
bridge down to the old DLL. On the other hand, maybe it's not
as reliable in getting back to the unmanaged code.
Once you enable /clr, all methods (regardless of whether they are global
methods or class members) get compiled as MSIL (but classes themselves
remain unmanaged types), unless they use a few special idioms (variable arg
methods, inline asm code, etc.) that force the compiler to generate them as
unmanaged code anyway, or you use #pragma unmanaged on them
Click to expand...

See, this is the kind of stuff I'm looking for to fill in gaps in
vague specs. It's tough to get a good intuitive feel for this.
The __nogc thing, whether it causes semantic changes, depends a lot on what
context you are using it, but, for the most part, in your example it should
cause non.
Click to expand...

Non?

Thanks
 
Back
Top