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?
right bit if I have a project with unmanaged and managed parts in it?
R
Ronald Laeremans [MSFT]
Yes.
Is there something more specific you are after?
Ronald Laeremans
Visual C++ team
Is there something more specific you are after?
Ronald Laeremans
Visual C++ team
S
songie D
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.
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?
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.
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?
T
Tomas Restrepo \(MVP\)
Songie,
Using a typedef is a simple way around it:
typedef System::Runtime::InteropServices::FILETIME NETFT;
NETFT tm....;
Header files would work just fine.
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).
Using a typedef is a simple way around it:
typedef System::Runtime::InteropServices::FILETIME NETFT;
NETFT tm....;
Header files would work just fine.
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).
G
Guest
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 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.
G
Guest
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.
The 'Form1.h' has 'using namespace' statements, and the stdafx.h has '#include <windows.h>'
There's no file in which there's both.
G
Guest
How would I compile one file without /clr and the rest with /clr, while building the project all at once?
A
Arnaud Debaene
Well, I must say I ran into a few problems with mixed MC++ / C++ whenRonald Laeremans said:
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
T
Tomas Restrepo \(MVP\)
Songie,
Select the file in question in solution explorer, and use the properties
dialog box to configure compiler arguments.
building the project all at once?
Select the file in question in solution explorer, and use the properties
dialog box to configure compiler arguments.
G
Guest
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.
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.
G
Guest
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
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
S
songie D
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!
contents of the system files. This isn't anything I've defined!
S
songie D
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.....
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:
M
MerkX Zyban
No.
T
Tomas Restrepo \(MVP\)
Songie,
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.
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.
A
Arnaud Debaene
Writing software is not about trust, faith or believe, it is aboutsongie D said:ah, so you're a non-truster I see aswell
I think I'll join you.
facts : I simply reported what I have observed, which has nothing to
do with GC, as I said.
Such childish reactions won't get you much attention here...
Arnaud
MVP - VC
S
songie D
Oh right, I see. But I don't see why I should have to if it's the
system files that have errored.
system files that have errored.
S
songie D
Arnaud Debaene said:
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.
S
songie D
That's an answer that's the exact opposite of someone else's.
Strangely, it's you who I believe.
Strangely, it's you who I believe.
R
Ronald Laeremans [MSFT]
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
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