Question about the dreaded MC++

[Ronald Laeremans [MSFT]]

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

 

[Ronald Laeremans [MSFT]]

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.

 

[Arnaud Debaene]

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.)

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

 

[Ronald Laeremans [MSFT]]

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

 

[Tomas Restrepo \(MVP\)]

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?