Boost logo

Boost :

From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2007-04-16 16:42:39

Peter Dimov wrote:
> Ion Gaztañaga wrote:
>> For objects that have no such default-state, and have no resource
>> reassignment functions (like reset() or similar) there is no problem
>> because there is no interface to reuse the object.
> I think I was with you until this point. It seems to me that the exact
> opposite is true; objects that have no "empty" or "default" state cannot
> implement a move, at least not easily, whereas reusing a moved-from object
> via assignment or reset is no problem at all.

Ok. So if such objects can't be moved, there is no problem to offer
reusability for other objects that can be moved ;-)

> FWIW, I've changed the shared_ptr move constructors and assignment operators
> to leave the source empty, but this doesn't mean that I'm convinced that the
> general case needs to be constrained in such a way. In particular,
> T& operator=( T && r )
> {
> swap( r );
> return *this;
> }
> seems a very reasonable implementation of move assignment, and has a slight
> performance advantage (one call to ~T instead of two in a typical use case)
> over
> T& operator=( T && r )
> {
> T( move( r ) ).swap( *this );
> return *this;
> }
> which is what is needed for r to be left empty.

Ok. Forget about the default constructed state. I don't want you to
deallocate the heap allocated reference count (you know I'm the leader
of the anti-allocate religion). Just tell me if move in terms of
swapping can lead to reusability.

Does it make any sense? If it does not, can you find a way so that you
get swap semantics *and* reusability is possible? The
default-constructed state was just a possibility, not the goal. My goal
is to left the objects in a consistent, usable state. If resources from
the previous move target have been stolen so that we can reuse them,
even better.



Boost list run by bdawes at, gregod at, cpdaniel at, john at