Question about the dreaded MC++

  • Thread starter Thread starter songie D
  • Start date Start date
S

songie D

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
 
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?
Click to expand...

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?
 
Songie,
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?
Click to expand...

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?
Click to expand...

Header files would work just fine.
Would I have to put #pragma unmanaged round the declaration?
Click to expand...

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).
 
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.
 
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
Click to expand...
building the project all at once?

Select the file in question in solution explorer, and use the properties
dialog box to configure compiler arguments.
 
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.
 
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
 
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!
 
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.....


Arnaud Debaene said:
"Ronald Laeremans [MSFT]" <[email protected]> wrote in message
Yes.

Is there something more specific you are after?
Click to expand...
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=...2&meta=group%3Dmicrosoft.public.vc.language.*
for the last dirty one.

Arnaud
MVP - VC
Click to expand...
 
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!
Click to expand...

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.
 
songie D said:
ah, so you're a non-truster I see aswell :-)
I think I'll join you.
Click to expand...
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...
Click to expand...
Such childish reactions won't get you much attention here...

Arnaud
MVP - VC
 
Oh right, I see. But I don't see why I should have to if it's the
system files that have errored.
 
Arnaud Debaene said:
"songie D" <[email protected]> wrote in message
Writing software is not about trust, faith or believe
Click to expand...

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.
 
That's an answer that's the exact opposite of someone else's.
Strangely, it's you who I believe.
 
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
 
Back
Top