Is auto_ptr allowed in managed C++ class

  • Thread starter Thread starter Jon
  • Start date Start date
J

Jon

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;
}
 
Hi Jon,

From my view of the code snippet, the struct S is not a mamaged(__gc)
class, and function consume is also compiled as native code for it included
inside the #pragma unmanaged block.


Thanks!

Best regards,

Gary Chang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------
 
Thanks for the reply.

Yes, I agree that the struct S{}, the function produce(), and the function consume() are unmanaged.

However, the function _tmain() is managed.
This _tmain() function uses these unmanaged functions as follows:
1) The function produce() constructs a S instance, wrapped in a temporary auto_ptr<S> instance.
2) The function consume() deletes this S instance which is wrapped in the temporary auto_ptr<S> instance.

My code snippet show that this S instance gets deleted twice!!!

So my question is: Is this a compiler bug, or are auto_ptr's are not allowed in managed code? .
 
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
 
Thank for the answer.

So the bottom line is, if I want reliable code, I should never cross a interop boundary with ant C++ object that has an destructor
that can not be called twice.

Too bad, I used a lot of auto_ptrs.
 
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
 
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
 
Back
Top