This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: Implementing clean and simple move symantics
- From: Joe Buck <Joe dot Buck at synopsys dot COM>
- To: Chris Jefferson <caj at cs dot york dot ac dot uk>
- Cc: libstdc++ at gcc dot gnu dot org
- Date: Tue, 23 Nov 2004 17:20:07 -0800
- Subject: Re: Implementing clean and simple move symantics
- References: <41A37998.6030306@cs.york.ac.uk>
On Tue, Nov 23, 2004 at 05:55:36PM +0000, Chris Jefferson wrote:
> [ approach to move semantics ]
>
> For most types T , using this involves 2 steps:
> 1) Add an overload to _Moveable while sets _M_type to 1.
> 2) Add a new constructor which takes _Moveable<T> t, performs default
> construction then does this->swap(t)
> 3) Add a new operator= which takes _Moveable<T> t and performs
> this->swap(t);
This will yield improvements for types where default construction is
cheap, and swapping is cheap. But it is inferior to what could be
achieved if you take advantage of objects that can be relocated by a
simple memmove. Consider std::vector<std::string>, where an element in
the middle of the vector is erased. Ideally, we would want to destroy the
deleted element, then use memmove to shift the whole array of strings back
by one (no need to adjust any reference counts). With your approach, it
appears that we must do N swaps (where N is the number of elements
following the deleted element), followed by the destruction of the element
to be deleted). It appears that at least three times as many word read
and word write operations are needed (the swap does three assignments
where the memmove needs one). If you're going to do the work of modifying
everything, you may as well have a vector class that is three times
faster.
Nevertheless, swap is better if you really need a swap, as you do in
sorting. I think that the move semantics work should support both
methods.