Re: [boost] move semantics

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-03-09 17:54:34

----- Original Message -----
From: <brangdon_at_[hidden]>
> 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.

Actually, this is debatable. You could instead destroy all or part of
the vector elements, so long as you leave only a (possibly empty)
contiguous region of constructed elements.

> 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 amount of code generated to handle the uncommon case should be taken
as a real consideration. However, I'm not convinced that it's
prohibitive in this case.

> The relocate version gives vector::insert the strong exception
guarantee.
> Using move construct only provides the basic guarantee.

?huh?

It was my impression that the difference between move and relocate is
that relocate leaves the source object destroyed whereas move does not.
I don't see how this could possibly change the available exception
guarantees, since you can always build relocate semantics (albeit
expensively) from move + destroy-source.

> This may be more
> important than any efficiency difference. Is move construct ever
useful
> for code that gives the strong guarantee?

Why wouldn't it be? Can you clarify your question a bit?

> The relocate version supports a wider range of classes.

I don't see how. If you can move, you can relocate. I think the converse
may be true, but I'm not sure of it.

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

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

I'm glad the thread isn't dead. You may need to review the context for
the rest of us, though...

-Dave