Re: [boost] move semantics

From: brangdon_at_[hidden]
Date: 2002-03-09 14:38:18

In-Reply-To: <668FF960-1C05-11D6-BB49-003065D18932_at_[hidden]>
On Thu, 7 Feb 2002 15:00:57 -0500 Howard Hinnant (hinnant_at_[hidden]) 
wrote:
> > It is not always practical for classes to define a null state with no
> > resources allocated.
> 
> As we've already explored, the optimum for vector::insert is to make 
> use of move construct and move assign.  I believe that vector::insert 
> could work with any of the following combination of tools:
> 
> 1.  move construct, move assign
> 2.  relocate construct, move assign
> 3.  copy construct, move assign
> 4.  copy construct, copy assign
> 
> [...]
> Up till now I had been thinking that vector (and swap) would simply 
> choose between two algorithms (1 or 4).  Either you can move or you 
> can't.  But certainly another valid approach would be to subdivide up 
> the question "can you move" into:  Can you move?  Can you relocate?

Is this getting too complicated?

I know you dislike vector::insert written in terms of relocate, because it 
has to undo the move if a copy fails. Still, this is doable. The code may 
be a bit grotty but it should be efficient in the common case, when an 
exception is not thrown. 

The relocate version gives vector::insert the strong exception guarantee. 
Using move construct only provides the basic guarantee. This may be more 
important than any efficiency difference. Is move construct ever useful 
for code that gives the strong guarantee?

The relocate version supports a wider range of classes. An optimisation I 
can't use is no good to me. The more generally applicable an optimisation 
is, the more likely vendors are to provide it. 

The simplicity of only having a single kind of move (ie relocate) is 
another benefit. (More on this below.)

Overall, I think the benefits of relocate outweigh the drawbacks.

> And clients of "move" (such as vector) would be under no obligation to 
> ask all of these questions and pick the very optimum.  Indeed, they can 
> simply stick with copy semantics if they want.  Or they could settle on 
> one of move or relocate.

Quite so. Maybe they will pick the wrong one, or maybe I will. Creating 
choices creates opportunities for mis-matched choices. Complexity is the 
enemy of efficiency.

-- Dave Harris

PS. Sorry to be commenting to such an old message. I wasn't able to keep 
up at the time. Discussion of this subject seemed to go very quiet shortly 
after your message.