Re: [boost] Re: Yo, move semantics anyone?

From: Joaquín Mª López Muñoz (joaquin_at_[hidden])
Date: 2004-04-14 12:59:05

David Abrahams ha escrito:

> Joaquín Mª López Muñoz <joaquin_at_[hidden]> writes:
>

[...]

>
> > Quick questions:
> >
> > * Seems like your library does not support the temporary return
> > part (I mean, the equivalent of mojo::fnresult). Is this right? If so,
> > are you planning to add support for this part as well?
>
> I don't know what you mean.  That hack is unneccessary with my
> library.  It's non-intrusive on clients of the movable class (unless
> they explicitly want to distinguish rvalue from const lvalue arguments
> for moving purposes). To return a movable class rvalue efficiently,
> you just return it.

Ok, I must be misunderstanding your comment about VRO. So,
what does this mean?

"Many compilers implement enough (N)RVO that implicit moving from"
"rvalues is unneccessary"

>
>
> Try the move.cpp test with --verbose-test on GCC to see what I mean.
>
> > * In those classes with fast swap, is this a right approach to implement
> > the move constructor?
> >
> > X(move_from<X> rhs)
> > {
> >   this.swap(rhs);
> > }
>
> Not usually; that will default-initialize all bases and members before
> doing the swap.
>

Yep, but I'm thinking about a container, where initializing to an
empy sequence is insignificant compared to copying the
whole elements of rhs. In the particular case of multi_indexed_container,
if this approach works it would achieve move semantics by adding about 20 lines
of a code to a single class (multi_index_container): indices proper wouldn't
have to care about move semantics at all.

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo