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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2003-01-28 13:10:30

From: "David B. Held" <dheld_at_[hidden]>
> "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? ;)

Nope, but I want my sink strongly exception safe; the pointer should be
deleted when a policy constructor throws. While you're at it, make the sink
support deep const (for deep copies, for example.)

More support for almost_default_storage_but_with_this_deleter would be nice
to have, too.

Apologies if the above issues have been addressed two years ago. I'm not
familiar with the latest & greatest SmartPtr. ;-)

> > 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. ;)

Yes, I understand that, but do you know of a user that needs an
almost_auto_ptr? ;-)

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

Move semantics in general could be useful, true, but vector<auto_ptr> isn't
supported, and it seems that this is a deliberate design decision.

Your memory is failing you, by the way. ;-)

http://lists.boost.org/MailArchives/boost/msg29886.php
http://lists.boost.org/MailArchives/boost/msg29925.php

A "move lock" is a good example of a resource that requires move semantics.
But the main problem with the current move solution is that a move-enabled
member doesn't make the enclosing class moveable, and the amount of work
required to make the wrapper moveable is pretty much constant regardless of
whether the members are move-enabled.

So move-enabling SmartPtr would only help me if I use it directly. In cases
like the above, though, I'll probably want to wrap it in a dedicated
move_lock class, since a lock is a very specific kind of SmartPtr, and it
might be desirable to prevent users from passing it to functions where a
SmartPtr is expected.