 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Languages / Managed C++ / May 2004Question about the dreaded MC++
Can managed C++ be trusted to handle the garbage collector correctly in the right bit if I have a project with unmanaged and managed parts in it? Yes. Is there something more specific you are after? Ronald Laeremans Visual C++ team > Can managed C++ be trusted to handle the garbage collector correctly in > the > right bit if I have a project with unmanaged and managed parts in it? > Yes. OK, good! I'd heard rumours that you "constantly have to worry about what the gc's doing", but I've not ran into any problems with that, as yet. > Is there something more specific you are after? ermm...yes, now you come to mention it. I'm trying to add using namespace System::Runtime::InteropServices; to my project, but it gives the error C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\PlatformSDK\Include\WinBase.h(3139) : error C2872: 'FILETIME' : ambiguous symbol could be 'C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\PlatformSDK\Include\WinDef.h(354) : _FILETIME FILETIME' or 'stdafx.cpp(0) : System::Runtime::InteropServices::FILETIME' many times. I can get round it by putting the explicit namespace name preceeding all calls to the namespace, but that's a bit cumbersome. Any idea how I can resolve it? Also, for having an unmanaged function in one separate .cpp file, and the managed code in what the IDE gives you (i.e. Form1.h), how would I link to the unmanaged function, using extern "C"? or other? Would I have to put #pragma unmanaged round the declaration? > Ronald Laeremans > Visual C++ team > > > Can managed C++ be trusted to handle the garbage collector correctly in > > the > > right bit if I have a project with unmanaged and managed parts in it? Songie, > ermm...yes, now you come to mention it. > I'm trying to add [quoted text clipped - 14 lines] > preceeding all calls to the namespace, but that's a bit cumbersome. Any idea > how I can resolve it? Using a typedef is a simple way around it: typedef System::Runtime::InteropServices::FILETIME NETFT; NETFT tm....; > Also, for having an unmanaged function in one separate .cpp file, and the > managed code in what the IDE gives you (i.e. Form1.h), how would I link to > the unmanaged function, using extern "C"? or other? Header files would work just fine. > Would I have to put #pragma unmanaged round the declaration? nope. You might want to put it on the definition of the function if you really want to ensure the compiler generates x86 code (instead of CIL) for it, though (although you could simply compile the containing .cpp file without /clr, as well).  SignatureTomas Restrepo tomasr@mvps.org How would I compile one file without /clr and the rest with /clr, while building the project all at once? Songie, > How would I compile one file without /clr and the rest with /clr, while building the project all at once? Select the file in question in solution explorer, and use the properties dialog box to configure compiler arguments. SignatureTomas Restrepo tomasr@mvps.org mmm... ok. You can do this, yes I've given up on using managed c++ anyway now, it seems that passing arrays is a whole lot more difficul than it is in c#, even though its in the same assembly. See further up posts. That's bollocks, there's no way you're supposed to change what's in the contents of the system files. This isn't anything I've defined! > Songie, > [quoted text clipped - 36 lines] > it, though (although you could simply compile the containing .cpp file > without /clr, as well). Songie, > That's bollocks, there's no way you're supposed to change what's in the > contents of the system files. This isn't anything I've defined! Who said you were supposed to change the contents of the system files? I just said you should use a typedef in YOUR sourcecode referencing a .NET CLASS to avoid having to always do the full-namespace+name thingie everywhere which you complained about. SignatureTomas Restrepo tomasr@mvps.org Oh right, I see. But I don't see why I should have to if it's the system files that have errored. > Songie, > [quoted text clipped - 5 lines] > CLASS to avoid having to always do the full-namespace+name thingie > everywhere which you complained about. Songie, > Oh right, I see. But I don't see why I should have to if it's the > system files that have errored. Huh? The system files are perfectly OK. It's not a problem, really, at all. It's just a name clash, which could happen with any code. Consider this perfectly valid C++ code: namespace X { class FILETIME { }; } using namespace X; int main() { FILETIME ft; } Now add #include <windows.h> on top of it and see what happens. Let me reinstate it: IT IS NOT A BUG. It's just the way C++ works. You have a type name that can be resolved to two different types within the same scope. You need to explicitly tell the compiler which one it is you mean. What's the big deal? SignatureTomas Restrepo tomasr@mvps.org Your problem is you are including a header, probally windows.h, after the using namespace statement. Just put all your includes before the using namespace statements to get rid of the errors There are some other problems with using the windows.h file and .Net in the same file. For example MessageBox is a macro, so if your trying to get System::Windows::Forms::MessageBox, you may find the compilier looking for System::Windows::Forms::MessageBoxA. To get around this you have to use #undef for the macro after including the header. This one is only a problem if you try to use MessageBox. There are no files with '#include' statements AND 'using namespace' statements The 'Form1.h' has 'using namespace' statements, and the stdafx.h has '#include <windows.h>' There's no file in which there's both. Your problem could be across multiple header files. For example, if your stdafx.h file includes the form1.h file before it includes the windows.h file it would cause the problem. If you look at the compilier output it should give the source file it was working on when it got the error. Looking at the order of includes from this file (and the files included by it) you might find the problem. You can also try changing the order of includes to see if it helps Header file conficts can be very tough to resolve because the compilier gives no information about what it has done to get there. I try to make it a habbit to avoid the things that can cause them. In this case I avoid "using namespace" statements in my header files. This leads to some rather verbose headers as every type needs an explicit namespace > Yes. > > Is there something more specific you are after? Well, I must say I ran into a few problems with mixed MC++ / C++ when you make heavy use of the RAII idiom : the .NET runtime seems to have difficulties with tracking lifetime of parameters, which can have some nasty side effects, even i f they are not related to GC. See http://groups.google.com/groups?hl=fr&lr=&ie=UTF-8&oe=UTF-8&threadm=16a4a8c7.040 4280815.2d93f31b%40posting.google.com&rnum=1&prev=/groups%3Fhl%3Dfr%26lr%3D%26ie %3DUTF-8%26oe%3DUTF-8%26q%3D%2522Bug%2Bincluding%2Ba%2Bstatic%2Blib%2Bin%2Ba%2BM C%252B%252B%2Bapplication%2522%26meta%3Dgroup%253Dmicrosoft.public.vc.language.* for the last dirty one. Arnaud MVP - VC ah, so you're a non-truster I see aswell :-) I think I'll join you. It does all seem like a big bag of shite all for the sake of IJW... but why you'd NEED existing code to compile managed I don't know..... > > Yes. > > [quoted text clipped - 10 lines] > Arnaud > MVP - VC > ah, so you're a non-truster I see aswell :-) > I think I'll join you. Writing software is not about trust, faith or believe, it is about facts : I simply reported what I have observed, which has nothing to do with GC, as I said. > It does all seem like a big bag of shite all for the sake of IJW... Such childish reactions won't get you much attention here... Arnaud MVP - VC > > ah, so you're a non-truster I see aswell :-) > > I think I'll join you. > Writing software is not about trust, faith or believe Oh god, it is. I can't see all the people for who the only language they will ever know in their lives is VB6, making a decent living in 10 years time. My best estimate is that the half life of any technical skill in this industry is a few years at most. So anyone that does not gain new skills on a constant basis throughput their career should really investigate their choice of field to work in. Ronald >> "songie D" <songie@D.com> wrote in message > news:<emahfv4NEHA.1420@TK2MSFTNGP09.phx.gbl>... [quoted text clipped - 5 lines] > will > ever know in their lives is VB6, making a decent living in 10 years time. Yes, this is a know issue and one where (in contrast to the answer you got) we do have different behavior for in Whidbey (i.e. the case you specifically posted will work in Whidbey) although we are still looking for a solution that will work in all cases. It doesn't specifically have to do with the garbage collector which is the question I was trying to answer. (The issue you posted the link to is a mostly a result of having different calling conventions between managed and native code on X86.) Ronald >> Yes. >> [quoted text clipped - 11 lines] > Arnaud > MVP - VC > Yes, this is a know issue and one where (in contrast to the answer > you got) [quoted text clipped - 9 lines] > calling > conventions between managed and native code on X86.) Interesting, thanks. I have also posted a reference to my previous post in the hope to gain a more complete answer from Microsoft :-) Is there any KB or paper available on the subject? How can a calling convention mismatch produce an abnormal call to a destructor? I hope it will be fixed soon, since smart-ptr or the like (that is, RAII) is a very common idiom in C++. For example, is it safe to use Alexandrescu's ScopeGuard (http://www.cuj.com/documents/s=8000/cujcexp1812alexandr/alexandr.htm) in an MC++ environnement? thanks again. Arnaud MVP - VC It is not a calling convention mismatch. The calling convention is different, so the CLR has to copy the arguments when going from native to managed code. There are 2 basic approaches, each with its sets of problems: 1) (What we do for 7.0 and 7.1). Have the CLR marshalling code try and call copy constructors and destructors. The specific issue you saw is that the copy constructor wasn't called from the user program so the linker threw the code out and then the CLR tried to call the non existent version. For which the workaround is to link with /opt:noref. A more insidious problem is that the CLR marshalling code does not have enough information to call the copy constructor and destructor in the right place which e.g. might lead to double destruction. 2) (What we are doing for Whidbey Beta 1.) Have the CLR marshalling code just do a bitwise copy. This will work correctly in all cases unless the classes are self referential in some way (i.e. the take their own address or the address of one of their members and store it away inside a member). The second solution will work with the implementation of ScopeGuard as given in the article. Ronald Laeremans Visual C++ team >> Yes, this is a know issue and one where (in contrast to the answer >> you got) [quoted text clipped - 27 lines] > Arnaud > MVP - VC No. > Can managed C++ be trusted to handle the garbage collector correctly in the > right bit if I have a project with unmanaged and managed parts in it? That's an answer that's the exact opposite of someone else's. Strangely, it's you who I believe. > No. > > > Can managed C++ be trusted to handle the garbage collector correctly in > the > > right bit if I have a project with unmanaged and managed parts in it? On the basis of what facts? Ronald > That's an answer that's the exact opposite of someone else's. > Strangely, it's you who I believe. [quoted text clipped - 4 lines] >> the >> > right bit if I have a project with unmanaged and managed parts in it? 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.