Mixing Mananged and Unmanaged in an Unmanaged class

[Jon]

Whether I can compile a class or not, depends on the order of functions in my class.

My question is (see example below):
1) Is it a bug that the class 'WillCompile' will compile and execute, or
2) or is it a bug that the class 'WillNotCompile ' will not compile?.

#include "stdafx.h"
#include <iostream>
#include <memory>
using namespace std;

#using <mscorlib.dll >

using namespace System;

#pragma unmanaged
class WillCompile {
public:
static void Umg() {
}
#pragma managed
static void Mng( String* str ) {
Console::WriteL ine( str );
}
};

#pragma unmanaged
class WillNotCompile {
public:
#pragma managed
static void Mng( String* str ) {
Console::WriteL ine( str );
}
#pragma unmanaged
static void Umg() {
}
};

#pragma managed
int _tmain()
{
WillCompile::Mn g( S"This works." );

Console::WriteL ine(S"Press Enter to continue.");
Console::ReadLi ne();
return 0;
}

[Gary Chang]

Hi Jon,

Currently I am looking for some resource to investigate this issue. We will
reply here with more information as soon as possible.
If you have any more concerns on it, please feel free to post here.
Thanks for your understanding!

Best regards,

Gary Chang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------

[Gary Chang]

Hi Jon

1) Is it a bug that the class 'WillCompile' will compile and execute, or 2) or is it a bug that the class 'WillNotCompile ' will not compile?.

Our Visual C++ team member Ronald confirmed these 2 scenarios are both as
designed, simply the rule is: any code that touches managed types must be
compiled as MSIL, any code that does not can be compiled either way.

Do you have any particular expectation or concern on this problem, if so,
please feel free to reply this message.
Thanks!

Best regards,

Gary Chang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------

[mccoyn]

From my testing, it appears that whether the class is managed is determined at the end of the definition. This seems at least a little bit unclear

1) WillNotCompile2 is just like WillCompile except it has an extra #pragma unmanaged at the end. This appears to make the whole class unmanaged, which creates the compilier error

2) WillCompile2 is just like WillNotCompile except it has an extra #pragma managed at the end. This appears to make the whole class managed, which avoids the compilier error

3) Changing the function order doesn't seem to have any affect, the only thing I can see as affecting whether it compiles or not is what the last #pragma statement within the class definintion is

This is just what I've determined from testing, I could be wrong. The MSDN page on it only mentions that #pragma affects how functions are compilied. It appears that it is affecting how classes are compiled as well

#pragma unmanage
class WillNotCompile2
public
static void Umg()

#pragma manage
static void Mng( String* str )
Console::WriteL ine( str )

#pragma unmanage
}

#pragma unmanage
class WillCompile2
public
#pragma manage
static void Mng( String* str )
Console::WriteL ine( str )

#pragma unmanage
static void Umg()

#pragma manage
}
http://msdn.microsoft.com/library/en...dUnmanaged.asp

[Jon]

So then, here is my confusion.

Does not "#pragma unmanaged" before a class, force it to be unmanaged?

If so, is this not a compiler bug?

#pragma unmanaged
class ThisIsManagedEv enWithPragmaUna managed {
public:
static void Umg() {
}
#pragma managed
static void Mng( String* str ) {
Console::WriteL ine( str );
}
};

I expected an error message, not a conversion to a managed class.

[Ronald Laeremans [MSFT]]

The class does not become "managed" i.e. it does not all of a sudden become
a __gc class. What you are getting is a class with the methods you do not
mark as #pragma managed being compiled to native code and the ones you do
explicitly mark so being compiled to MSIL.

Ronald Laeremans
Visual C++ team

"Jon" <jo*@martinsoun d.com> wrote in message
news:%2******** ********@tk2msf tngp13.phx.gbl. ..

So then, here is my confusion.

Does not "#pragma unmanaged" before a class, force it to be unmanaged?

If so, is this not a compiler bug?

#pragma unmanaged
class ThisIsManagedEv enWithPragmaUna managed {
public:
static void Umg() {
}
#pragma managed
static void Mng( String* str ) {
Console::WriteL ine( str );
}
};

I expected an error message, not a conversion to a managed class.

[mccoyn]

That doesn't really explain why one class would compile, while another one which just had the functions in a different order didn't compile. If the #pragma statements are truly only affecting the functions, then the only difference between the two classes is the function order. Thats something that usally doesn't affect whether it compiles or not.

[Jon]

Thanks. So #pragma (un)managed works only for functions.

So the confusion is when does a mixed manage/unmanged class
produces a compile error and when does it produces a __gc class?

class ThisCompilesAsG c {
#pragma unmanaged
static void Umg() { }
#pragma managed
static void Mng( String* str ) { Console::WriteL ine( str ); }
};

class ThisDoesNotComp ile {
#pragma managed
static void Mng( String* str ) { Console::WriteL ine( str ); }
#pragma unmanaged
static void Umg() { }
//error C3280: 'ThisDoesNotCom pile::Umg' : a member-function of a managed type cannot be compiled as an unmanaged function
};

[Yan-Hong Huang[MSFT]]

Hi Russell,

From MSDN, we can see that:
"It is not valid to declare a member of an unmanaged class to have __gc pointer type. In order to "point" to a managed object from the C++
heap, the header file vcclr.h provides the type-safe wrapper template gcroot. Use of this template allows the programmer to embed a virtual
__gc pointer in an unmanaged class and treat it as if it were the underlying type"

Please refer to http://msdn.microsoft.com/library/de...sSpec_16_3.asp.

Also, don't use #pragma unmanaged, #pragma managed inside a class. If you want to define such functions, move it out of the classes.

Thanks.

Best regards,
Yanhong Huang
Microsoft Community Support

Get Secure! ¨C www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

[Russell Hind]

Yan-Hong Huang[MSFT] wrote:

Hi Russell,

From MSDN, we can see that:
"It is not valid to declare a member of an unmanaged class to have __gc pointer type. In order to "point" to a managed object from the C++
heap, the header file vcclr.h provides the type-safe wrapper template gcroot. Use of this template allows the programmer to embed a virtual
__gc pointer in an unmanaged class and treat it as if it were the underlying type"

Please refer to http://msdn.microsoft.com/library/de...sSpec_16_3.asp.

Also, don't use #pragma unmanaged, #pragma managed inside a class. If you want to define such functions, move it out of the classes.

I understand that, but my point was that this doesn't compiler

__gc class GCTest_c;

#pragma unmanaged
class Test_c
{
public:
Test_c(void)
{
}

private:
gcroot<GCTest_c *> m_Test;
};

There is no pragma in the class, the class and hopefully all functions
will be unmanaged, but it doesn't compile because of the gccroot variable.

Take the example from the link you posted. If you put #pragma unmanaged
abot class CppClass_c, it won't compile.

// mcpp_nested_cla sses7.cpp
// compile with: /clr
#using <mscorlib.dll >
#include <vcclr.h>
using namespace System;

#pragma unmanaged
class CppClass {
public:
gcroot<String*> str; // can use str as if it were String*
CppClass() {}
};

int main() {
CppClass c;
c.str = new String("hello") ;
Console::WriteL ine( c.str ); // no cast required
}

Is this a bug, or do all non gc classes that contain gccroot variables
have to be compiled as managed?

Thanks

Russell