From: Howard Hinnant (hinnant_at_[hidden])
Date: 2002-02-06 19:42:29
On Wednesday, February 6, 2002, at 03:56 PM, Sean Parent wrote:
> It was correctly pointed out, that swap can be implemented using
> constructing moves (in the same way it is done with copying, through a
> temp). But in the case of a non-POD class, I don't think this is a win
> unless you define the source from the move to have been destructed as a
> result of the move (call this relocate).
>
> The move vs. relocate semantics would be:
>
> move - moving a source A into uninitialized memory B. The result leaves
> A in
> an indeterminate but destructible state. "Copy" construction of an
> auto_ptr
> is an example.
>
> relocate - moving a source A into uninitialized memory B. The result
> leaves
> A in a destructed state. Requires the source A is also managed with
> placement new and delete.
I like these definitions, except I would also like to see moving into
initialized memory defined (e.g. auto_ptr assignment). They make it
easier to discuss the variations.
I'm not understanding your comments with respect to swap implemented
with move though:
template <class T>
void
swap(T& a, T& b)
{
T tmp(move(a)); // move construct
a = move(b); // move assign
b = move(tmp); // move assign
}
None of these was intended to be a relocation, though the last move from
tmp certainly could be since the next (implied) statement is the
destruction of tmp.
> The relocate construct would be useful for container optimization -
> but I
> think the complexities of implementing it for anything that can't be
> treated
> as a POD (just do a memcopy for the relocate) is difficult. It may be
> worth
> having a trait though for objects that can use memcopy to relocate.
I don't think relocation will be useful for container optimization, at
least not vector. I went into this in some detail under the auto_vector
subject. I remain unconvinced (but open minded) about its usefulness in
general.
> The first item, I think is simplest to implement using a non-throwing
> constructor (one that constructs an object upon which the only valid
> operation is destruction) and a swap.
I suspect we've got a time delay thing going on. I just got your post,
but it is dated hours earlier. Have you had a chance to look at
Hamish's proposed code, and my response to it? Your comments on this
would be most valued.
-Howard