[boost] Re: Perfect moving (almost)

From: David B. Held (dheld_at_[hidden])
Date: 2004-02-11 02:37:51

"Daniel Wallin" <dalwan01_at_[hidden]> wrote in message
news:4028DF54.2020303_at_student.umu.se...
> > [Me...]
> > template <typename U, policies...>
> > smart_ptr(smart_ptr<U, policies> const&p);
> >
> > template <typename U, policies...>
> > smart_ptr(smart_ptr<U, policies>&p);
> >
> > These two c'tors are still in the code.  Do you think that will
interfere
> > with the move semantics when doing a move-convert?  i.e.:
>
> No it should work as expected. This specialization forbids construction
> from lvalues, conversions too.
>
>    template<class U, BOOST_CONVERSION_PARAMETERS>
>    struct cant_move_from_const<
>        const smart_ptr<U,  BOOST_CONVERSION_POLICIES>
>    >;

I don't see how.  This only gets "activated" during a call to:

template <typename P>
smart_ptr(P&, cant_move...<>);

But, in this case:

smart_ptr<Base, destructive_copy> p(
    smart_ptr<Derived, destructive_copy>(new Derived)
);

The better match is not smart_ptr(P&) but rather
smart_ptr(smart_ptr<U>&), because the latter is more specialized.
This seems to totally circumvent your system.  Does the conversion
c'tor also need to use the cant_move device?  I.e.:

template <typename U, policies...>
smart_ptr(smart_ptr<U, policies>&p, cant_move..);

Also, I can't use these changes at all anyway right now, because
even gcc 3.3.2 doesn't like it.  It likes it fine if you only have move
pointers.  But for some reason, it instantiates the move policies
during tests with non-move configurations, which I'm pretty sure is
a bug in gcc that I don't have time to isolate and report right now.
And if the latest gcc doesn't like it, I have little hope for other
compilers.  If you are interested in trying to diagnose the problem
yourself, I will try to update the sandbox with my working version.

Dave

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.581 / Virus Database: 368 - Release Date: 2/9/2004