Mixing Mananged and Unmanaged in an Unmanaged class

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

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::WriteLine( str );
}
};

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

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

Console::WriteLine(S"Press Enter to continue.");
Console::ReadLine();
return 0;
}
 
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.
--------------------
 
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?.
Click to expand...

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.
--------------------
 
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::WriteLine( str )

#pragma unmanage
}

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

#pragma unmanage
static void Umg()

#pragma manage
}


http://msdn.microsoft.com/library/en-us/vclang/html/vcerrManagedUnmanaged.asp
 
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 ThisIsManagedEvenWithPragmaUnamanaged {
public:
static void Umg() {
}
#pragma managed
static void Mng( String* str ) {
Console::WriteLine( str );
}
};

I expected an error message, not a conversion to a managed class.
 
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
 
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.
 
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 ThisCompilesAsGc {
#pragma unmanaged
static void Umg() { }
#pragma managed
static void Mng( String* str ) { Console::WriteLine( str ); }
};

class ThisDoesNotCompile {
#pragma managed
static void Mng( String* str ) { Console::WriteLine( str ); }
#pragma unmanaged
static void Umg() { }
//error C3280: 'ThisDoesNotCompile::Umg' : a member-function of a managed type cannot be compiled as an unmanaged function
};
 
Hi Jon,

I was reviewing it and will consult our compiler team on the cause of this behavior. I will return here with more information as soon as possible.

Thanks very much for your patience.

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.
 
Hi Jon,

I submited a request to our product group and let them look into this issue.

The conclusion is that this should be considered a product issue with obvious workarounds. In Whidbey, we currently issue a warning and
ignore the pragma:

warning C4177: #pragma 'managed' should only be used at global scope or namespace scope

We specifically decided we would not support this #pragma's within the definition of a class - if you define the function outside of the class
then the #pragma's work. You can see it in VS Whidbey.

So all things is quite clear now. If you feel there is any we can do, please feel free to post here and we will follow up.

Thanks very much.

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.
 
Hi Jon,

A quick update.

We decided to make it an error, not a warning. The workaround is to define the function outside the class.

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.
 
Yan-Hong Huang said:
We decided to make it an error, not a warning. The workaround is to define the function outside the class.
Click to expand...

So the compiler decides whether the function is managed or unmanaged at
the point it is defined (implemented) not declared?

I have a problem in that if I have #pragma unmanaged before a class (non
gc class), and the class contains a gcroot<T*> as a private memeber,
then I get compiler errors. Inserting a #pragma managed and unmanaged
around the declaration solve this. e.g.

__gc class GCTest_c;

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

private:
gcroot<GCTest_c*> m_Test;
};

This doesn't compile, but can be fixed by putting #pragam
managed/unmanged around the m_Test declaration. e.g.

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

private:
#pragma managed
gcroot<GCTest_c*> m_Test;
#pragma unmanaged
};

But according to your replies, this shouldn't be done. So is this a bug?

Thanks

Russell
 
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/d...cmxspec/html/vcManagedExtensionsSpec_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.
 
Yan-Hong Huang said:
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/d...cmxspec/html/vcManagedExtensionsSpec_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.
Click to expand...

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_classes7.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::WriteLine( 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
 
It is not a bug. Please put #pragma managed before the definition of the class. Don't use #pragma unmanaged, which let the method in the class
all unmanaged and so can't use gcroot.

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.
 
Yan-Hong Huang said:
It is not a bug. Please put #pragma managed before the definition of the class. Don't use #pragma unmanaged, which let the method in the class
all unmanaged and so can't use gcroot.
Click to expand...

Ok, but I was trying to get all methods 'unmanaged' apart from one which
is used to call a method on the gcroot object.

Cheers

Russell
 
Russell said:
Ok, but I was trying to get all methods 'unmanaged' apart from one which
is used to call a method on the gcroot object.
Click to expand...

The code in question was:

__gc class GCTest_c;
#pragma unmanaged
class Test_c {
public:
Test_c(void) { }
private:
gcroot<GCTest_c*> m_Test;
};

You have to assume that any use of the gcroot<T> object will require
doing managed things, including constructing it and destroying it.
Therefore, all the constructors and the destructor of the class must be
compiled as managed code, even if they don't explicitly reference the
gcroot<T> object.
 
David said:
The code in question was:

__gc class GCTest_c;
#pragma unmanaged
class Test_c {
public:
Test_c(void) { }
private:
gcroot<GCTest_c*> m_Test;
};

You have to assume that any use of the gcroot<T> object will require
doing managed things, including constructing it and destroying it.
Therefore, all the constructors and the destructor of the class must be
compiled as managed code, even if they don't explicitly reference the
gcroot<T> object.
Click to expand...

Thanks, I'd forgotten about the default copy constructors etc that are
generated. I wonder if they really need to be managed as they only copy
the gcroot object?

Cheers

Russell
 
Russell said:
Thanks, I'd forgotten about the default copy constructors etc that are
generated. I wonder if they really need to be managed as they only copy
the gcroot object?
Click to expand...

But gcroot objects are never simply copied. The gcroot copy constructor
creates a new GC handle, which uses managed types and calls managed
functions. Every single function in gcroot<T> (including constructors,
destructor, and assignment operators) calls managed functions. Every
single function is also inline. So to be safe, all uses of gcroot
should be within managed code.
 
Back
Top