 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Languages / Managed C++ / February 2008Managed/Unmanaged code and #pragma managed/unmanaged
Hello, I am hoping someone can clear up some confusion I have as seemingly (like all things C++/CLI it seems) there isn't too much information out there. I have a load of unmanaged C++ that has been built up over the years and performs well. I have some C++/CLI code that uses this unmanaged code seemingly quite well (although I do worry that the performance is not as good as it should be due to my lack of knowledge) The unmanaged C++ code uses a lot of BOOST stuff and this raises other issues (more on that later). The setup I have is the unmanaged code is in a series of .LIBs. I then have a /CLR compiled project that links against these libs. I mainly have classes in the /CLR project that creates a managed wrapper for the unmanaged code. Then I have some ASP.NET code that uses this assembly. The questions I have on this setup are:- (1) Should I be wrapping #included UNMANAGED headers with #pragma unmanaged, #pragma managed block? (I currently do - but read on MSDN and on this newsgroup that this is a no-no) The reason I ask is I cant get my head around what the compiler will do when it encounters one of my unmanaged headers in a file compiled with /CLR. I am particularly concerned as I use things like boost::shared_ptr in my unmanaged code. Does the /CLR option cause the compiler to try to convert the included stuff into C++/CLI compatible code? One of my reasons for doing this was that I was getting no end of grief trying to use BOOST 1_34_1 and this thread (see at the bottom) http://www.thescripts.com/forum/thread701525.html Suggested this approach. (2) If say I have a std::vector containing a load of pointers (well boost::shared_ptrs) is there any harm in passing this around C++/CLI Managed code? What I wonder is if I am providing a wrapper class for the unmanaged code am I expected to extract all the data from the std::vector and put it into managed structures? So that the #includes for unmanaged code is only in one cpp file (say)? Many thanks for your time. A. > Hello, > [quoted text clipped - 21 lines] > unmanaged, #pragma managed block? (I currently do - but read on MSDN > and on this newsgroup that this is a no-no) That works well for me. I'm actually trying to prevent any managed code from running on a particular thread, to prevent the GC from pausing it. Can you provide a link to the MSDN article which you think discourages this? > The reason I ask is I cant get my head around what the compiler will > do when it encounters one of my unmanaged headers in a file compiled [quoted text clipped - 22 lines] > > A. > ajtay...@hushmail.com wrote: > > Hello, [quoted text clipped - 54 lines] > > > A. http://msdn2.microsoft.com/en-us/library/0adb9zxe.aspx Use the following guidelines when applying these pragmas: Add the pragma preceding a function but not within a function body. Add the pragma after #include statements (do not use these pragmas before #include statements). Also in the book Expert C++/CLI by Marcus Heege P170 He basically recommends that you don't do it. > http://msdn2.microsoft.com/en-us/library/0adb9zxe.aspx > > Use the following guidelines when applying these pragmas: > > Add the pragma preceding a function but not within a function > body. This is because any function is either native or managed, you can't mix. (However a template function might be able to create some native instantiations and some managed instantiations from the same source, but there still is no mixing). > Add the pragma after #include statements (do not use these > pragmas before #include statements). Ideally the header files should contain the pragma managed push/pop, this helps ensure that any particular declaration has the same pragma in effect in every compilation unit. For purely native third-party headers, rather than modify the third-party headers, you might have to place the pragma before a #include. To help ensure this is done consistently, create a wrapper header file that sets pragmas correctly (including managed, packing, etc), then includes the unmodified third-party header. > Also in the book Expert C++/CLI by Marcus Heege P170 > > He basically recommends that you don't do it. In some situations it may be unavoidable. In other cases it may help work around a compiler bug. > >http://msdn2.microsoft.com/en-us/library/0adb9zxe.aspx > [quoted text clipped - 28 lines] > In some situations it may be unavoidable. In other cases it may help work > around a compiler bug. Thanks for your reply. What I don't understand is I have created two assemblies and they both follow a simple design ManagedClass contains an unmanaged ptr to an unmanaged class. This managed class provides a managed interface to some unmanaged code (this is compiled with /clr). The unmanaged class has a simple interface and only uses std::string over and above doubles/ints etc... In the implementation of this class (in the cpp file) more complex unmanaged types are used (including BOOST). This is all compiled as unmanaged C++ The Only #include in the unmanaged C++ class header file is #include <string> Now, I use one of these assemblies and all works fine. The other one crashes with the is not a valid Win32 application. (Exception from HRESULT: 0x800700C1) error. The only way to solve this is to wrap the #include of the unmanaged header with the pragmas in the managed class implementation file. ManagedClass.cpp #pragma unmanaged #include "UnManaged.h" #pragma managed Fair enough if this is the way you have to do it - but a) Its inconsistent the fact that one assembly works and the other doesn't despite being almost identical in code (and certainly identical in design) b) I though IJW should "just work" I can see how including a unmanaged c++ header that #includes a std::string should cause runtime crashes unless I use the #pragrmas. I am finding C++/CLI development incredibly frustrating to say the least. Many thanks. A > The only way to solve this is to wrap the #include of the unmanaged > header with the pragmas in the managed class implementation file. [quoted text clipped - 4 lines] > #include "UnManaged.h" > #pragma managed If UnManaged.h is your own source code (not 3rd party), I recommend that you put the following there: #ifdef _MANAGED #pragma managed(push, off) #endif #include ... // your unmanaged includes class ... // your unmanaged classes #ifdef _MANAGED #pragma managed(pop) #endif This is what Ben meant by "pragma managed push/pop". This way you can simply #include "UnManaged.h" from managed code. There are many subtle details when you mix managed and unmanaged code. Here's one more thing that you should watch out for: http://tinyurl.com/ytlyqd Tom > ajtay...@hushmail.com wrote: > > The only way to solve this is to wrap the #include of the unmanaged [quoted text clipped - 29 lines] > > Tom Thanks for the reply. I will add that to my code and see if that cures the inconsistencies I am seeing. BTW: I think some of my issues are stemming from using BOOST in my code and it seems that I only started seeing these issues when I went to SP1 in VS2005.
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.