Is auto_ptr allowed in managed C++ class

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Jon - 22 May 2004 00:06 GMT

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;
}

Reply to this Message

Gary Chang - 22 May 2004 09:29 GMT

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

Signature

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

--------------------

Reply to this Message

Jon - 23 May 2004 15:04 GMT

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

Reply to this Message

Ronald Laeremans [MSFT] - 24 May 2004 23:49 GMT

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

> Is auto_ptr allowed in managed C++ class?
>
[quoted text clipped - 36 lines]
> return 0;
> }

Reply to this Message

Jon - 25 May 2004 01:01 GMT

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.

Reply to this Message

Steve McLellan - 25 May 2004 13:58 GMT

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

> Hi Jon,
>
[quoted text clipped - 48 lines]
> > return 0;
> > }

Reply to this Message

Ronald Laeremans [MSFT] - 25 May 2004 17:31 GMT

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

> 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
[quoted text clipped - 60 lines]
>> > return 0;
>> > }

Reply to this Message

Rate this thread:

Is auto_ptr allowed in managed C++ class

Free Magazines