auto_ptr pass-by-value to a method results in erroneous object destruction

Hello All,

I have a situation that appears to be a compiler or STL bug.

I have a class Expression_Binary_Operator which has the following
method:

void  Expression_Binary_Operator::Set_Left_Chi
ld( auto_ptr<
Expression_Node > _ap_Left_Child )
{
// ap_Left_Child is a member variable!
ap_Left_Child = _ap_Left_Child;
}

I have some calling code which does roughly this:

// class Expression_Variable : public Expression_Node ...

auto_ptr< Expression_Binary_Operator > ap_bin_op( new
Expression_Binary_Operator( /* some args */ ) );

auto_ptr< Expression_Variable > ap_variable( new Expression_Variable(
/* some args */ ) );

ap_bin_op->Set_Left_Child( ap_variable );

Note that in my case the auto_ptr's are different types but compatible
(because Expression Node is a based class of Expression_Variable, as
the comment notes).

Now, the ownership semantics of auto_ptr *should* mean that ownership
(and the pointer) are transferred first to the pass-by-value argument
then on to the ap_Left_Child member variable of
Expression_Binary_Operator.

In my case I am seeing, directly after the call to Set_Left_Child
returns, that the object pointed to by ap_variable is being destroyed.
The my_binary_operator object is still in existence, and when it
destructs, it also (via its auto_ptr) tries to destroy the same
object, resulting in a double-destruction and crash.

The code for Set_Left_Child is compiled Native C++ code sitting in a
static link library and the calling code is compiled with /CLR.

Is this a known problem?

Thanks

Kevin Frey wrote:
> Hello All,
>
> I have a situation that appears to be a compiler or STL bug.

<snip description of problem>

> Is this a known problem?

First, you need to say what compiler version and standard library you are us
ing
before a complete answer can be given.

Second, your example seems to be a case of the "copy-initialization from lva
lue
with derived-to-base conversion", which was discovered not to work as expect
ed.
See

http://www.open-std.org/jtc1/sc22/w...active.html#463

and also the table here:

http://www.kangaroologic.com/move_p...dex.html?path=6

In general, it's best to avoid derived-to-base conversions with auto_ptr.

For fun, you might try:

auto_ptr< Expression_Binary_Operator > ap_bin_op( new
Expression_Binary_Operator( /* some args */ ) );

ap_bin_op->Set_Left_Child(
auto_ptr< Expression_Variable >(new Expression_Variable(...))
);

Jonathan

> First, you need to say what compiler version and standard library you are using
> before a complete answer can be given.
>

I am using Microsoft Visual Studio .NET 2003 with the standard STL
(Dinkumware) that ships with the product.

> Second, your example seems to be a case of the "copy-initialization from l
value
> with derived-to-base conversion", which was discovered not to work as expected.[/c
olor]

I had tried various combinations that should have eliminated the
"derived-to-base conversion". For example, I tried:

my_bin_op->Set_Left_Child( auto_ptr< Expression_Node >(
ap_variable.release( ) );

Kevin Frey wrote:

> The code for Set_Left_Child is compiled Native C++ code sitting in a
> static link library and the calling code is compiled with /CLR.

Have you tried calling the code in question from native code?

I recall that there is a problem with double-destruction (or something like
that) in certain interop cases from managed -> native code.

-cd

> Have you tried calling the code in question from native code?

Yes. A simple test program that is compiled entirely either as native
or managed code (ie. no interop involved) works perfectly.

We know the idiom works fine be we heavily use the idiom in our
"server" code which is compiled all as native code.

So therefore I believe there is a problem due to the
managed-code->native code behaviour and I am sing clarification if
this is indeed the case.

Kevin Frey wrote: 

> So therefore I believe there is a problem due to the
> managed-code->native code behaviour and I am sing clarification if
> this is indeed the case.

Sorry I missed the line about compiling with /CLR

Jonathan