Help: auto_ptr conversion confusion

Thu Oct 31 10:23:00 GMT 2002

----- Original Message -----
From: "Benjamin Kosnik" <>
To: "gp" <>
Cc: <>
Sent: Monday, October 28, 2002 7:29 PM
Subject: Re: Help: auto_ptr conversion confusion

> >Excuse me for jumping in; I don't follow this list (my first time! :-),
> >thought I would like to
> >have time to do it. But does g++ 3.2 already implement the resolution of
> >core issue 84?
> Just
>  127.  auto_ptr<> conversion issues
> apparently. If you'd like to submit a patch, I'm sure that would be
> useful.

Well, there must be something else that isn't implemented according to the
standard then (probably the second step of copy-initialization, but if so
that's not necessarily bad - see below).

Please, read core issue 84 carefully:

The problem is in the formulation of copy-initialization

    struct A {};
    struct B: A {};

    auto_ptr<B> f()
       auto_ptr<B> b;
       return b;

    int main()
       auto_ptr<A> a = f();   // (1)
       return 0;

It's obvious that line (1) requires copy initializing an auto_ptr<Base> from
an auto_ptr<Derived> rvalue. According to 8.5/14 without the corrections of
core 84 to do that you apply a two step process where you first find a
conversion from auto_ptr<Derived> to auto_ptr<Base> then go on as if it was
a direct-initialization from the object obtained in the first step. In our
case that means:

       1st step:    template<class U> auto_ptr<Derived>::operator
auto_ptr<U>() throw();   [for U = Base] - It gives you a temporary.

       2nd step:   direct initialization from the temporary; as we know,
that goes through auto_ptr<Base> -> auto_ptr_ref<Base> -> auto_ptr<Base>

 The proposed resolution of core issue 84 inhibits using the user-defined
conversions in the second step, and thus makes the code above ill-formed.


More information about the Libstdc++ mailing list