Sorry, there is no version yet that I can share. Or that is worth sharing
yet for that matter.
Bottom line: do not pass C++ objects across an interop boundary by value if
they cannot survive double destruction. In almost all cases (but of course
not in the case of auto_ptr where it defeats the purpose) passing them by
const reference is a good workaround.
Ronald
"Steve McLellan" <sjm.NOSPAM AT fixerlabs DOT com> wrote in message
news:e7**************@TK2MSFTNGP10.phx.gbl...
This sounds a bit ominous... Is there a version of this knowledgebase
article about? We're only a few weeks from release and undocumented stuff
like this isn't that welcome at the minute.
Cheers,
Steve
"Ronald Laeremans [MSFT]" <ro*****@online.microsoft.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl... Hi Jon,
There is a know issue (that has a knowledgebase article in the process of
being written) in that in some cases passing a C++ object through an
interop boundary by value can lead to double destruction of the object. This
aspect of the problem is fixed in the Whidbey release for types that are not
self
referential (in taking the address of this or one of the members and
storing it away).
Ronald Laeremans
Visual C++ team
"Jon" <jo*@martinsound.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl... > Is auto_ptr allowed in managed C++ class?
>
> I have my doubts because of the following example:
>
> #include "stdafx.h"
> #include <iostream>
> #include <memory>
> using namespace std;
>
> #using <mscorlib.dll>
>
> using namespace System;
>
> #pragma unmanaged
> int ctorDtorCount = 0;
>
> struct S {
> S() {
> ++ctorDtorCount;
> }
> ~S() {
> --ctorDtorCount;
> if( ctorDtorCount < 0 )
> throw "Error";
> }
> };
>
> auto_ptr<S> produce() {
> return auto_ptr<S>( new S() );
> };
>
> void consume( auto_ptr<S> s ) {
> }
> #pragma managed
>
> int _tmain()
> {
> consume( produce() );
> return 0;
> }
>
>