David Abrahams ha escrito:
Joaquín Mª López Muñoz <joaquin@tid.es> 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