Boost logo

Boost :

Subject: Re: [boost] [move][container] Review Request (new versions of Boost.Move and Boost.Container in sandbox and vault)
From: David Abrahams (dave_at_[hidden])
Date: 2009-08-12 15:00:11

on Wed Aug 12 2009, Ion Gaztañaga <> wrote:

> David Abrahams escribió:
>> Very great news to hear that this project is moving forward (so to speak
>> ;-))
> Let's hope this is the final step!
>>> The library has now new macros to declare copyable and movable types and movable
> only
>>> types. Old macros are still there for backwards compatibility (specially unordered
>>> library which was also ported to this move sandbox) but I expect to remove them if
>>> current approach is considered better.
>>> ->Updated documentation and tests.
>> still says "all moves occur explicitly," but I think you mean "all moves
>> from lvalues," right?
> Yes. The new library now moves non-const rvalues in assignments:
> copyable_and_movable produce();
> copyable_and_movable cm;
> for(;;){
> //now moved instead of copied!
> cm = produce();
> }

Only in assignments?

  what about



> This is not the case with constructors (the original Klaus Triendl proposal included
> them, because it terribly
> uglifies syntax

Are you sure you've looked at all the alternatives? Every move library
I'm aware of before yours supports implicitly move constructing from
non-const rvalues.

> (there is no way in C++03 to automatically generate constructor
> overloads that forward to another constructor) and because that case is in practice
> more efficient than moving thanks to RVO:
> for(;;){
> //Copied? No, RVO avoids copy
> copyable_and_movable cm = produce();
> }

You might check whether direct initialization is just as
efficient as copy initialization before you say that:

  copyable_and_movable cm((produce()));

IIRC EDG-based compilers used to only elide copies in the copy
initialization case (!)

Dave Abrahams
BoostPro Computing

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