 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Languages / Managed C++ / June 2004Mixing Mananged and Unmanaged in an Unmanaged class
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  SignatureGet 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?. 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 SignatureGet Secure! - www.microsoft.com/security This posting is provided "AS IS" with no warranties, and confers no rights. -------------------- 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 > So then, here is my confusion. > [quoted text clipped - 14 lines] > > I expected an error message, not a conversion to a managed class. 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. > We decided to make it an error, not a warning. The workaround is to define the function outside the class. 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/default.asp?url=/library/en-us/vcmxspec/html/v cManagedExtensionsSpec_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. > Hi Russell, > [quoted text clipped - 6 lines] > > 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_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. > 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. 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 >> 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. > > Ok, but I was trying to get all methods 'unmanaged' apart from one which > is used to call a method on the gcroot object. 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. SignatureDavid Olsen qg4h9ykc5m@yahoo.com > The code in question was: > [quoted text clipped - 12 lines] > compiled as managed code, even if they don't explicitly reference the > gcroot<T> object. 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 >> The code in question was: >> [quoted text clipped - 16 lines] > generated. I wonder if they really need to be managed as they only copy > the gcroot object? 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. SignatureDavid Olsen qg4h9ykc5m@yahoo.com 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 Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.