[boost] Re: Re: SmartPtr (Loki) - auto_ptr/move c'tor issue

From: David B. Held (dheld_at_[hidden])
Date: 2003-01-28 12:24:04

"Peter Dimov" <pdimov_at_[hidden]> wrote in message
news:001901c2c6ea$e2576360$1d00a8c0_at_pdimov2...
> [...]
> You can use this argument for any feature. But you can't include all
> features.

Watch me try. Did you want that sink in any particular color? ;)

> > At the very least, it seems like a glaring omission to create a smart
> > pointer framework that can't even emulate auto_ptr<>.
>
> It depends on what your design goals are. If you want to create the
> One True Smart Pointer Design, then yes, auto_ptr<> emulation is a
> must.

I think this is a good goal. ;>

> If, on the other hand, you want to create the Design That Solves
> Common User Needs, auto_ptr<> emulation isn't high on the list.
> If I need auto_ptr I know where to find it, and nobody I know has
> ever written an auto_ptr (amusement aside.) :-)

The point is, auto_ptr<> has fixed semantics.  We don't want to
touch the base semantics, which involve move, of course.  We simply
want to allow the user to do a few extra things with auto_ptr<> that
she cannot do with std::auto_ptr<> without having to roll her own
version, no matter how much fun that might be. ;)

> > Beyond that, it seems that there are resources that would
> > benefit from or outright require move semantics to work properly,
> > and why wouldn't you want to let SmartPtr<> manage those?
>
> Interesting question. Do you have an example?

You would call me on that, wouldn't you?  Ok, I can't think of a
resource that would *require* move semantics (which is why I didn't
mention one in the first place, but I hoped maybe someone more
imaginative than I would pipe up with an example ;).  However, it still
seems that move semantics would be useful in a std::vector<>.  You
might know that the vector holds the only pointers to the resources,
and resizing the vector does not incur the overhead of modifying a
bunch of counts.

> Also note that I said "in current C++" (that's rather move semantics
> unfriendly.) Given language support for move (N1377 for example),
> it would make perfect sense to extend SmartPtr with move semantics,
> of course.

I agree that native move facilities would be nice.  But auto_ptr<> like
move semantics have established a large historical precedent, and
people find it useful enough until we get real move support, that I
think it ought to be supported.

Dave