Boost logo

Boost :

Subject: Re: [boost] [Move] Documentation Notes/Questions
From: David Abrahams (dave_at_[hidden])
Date: 2012-10-29 19:56:15

on Sun Oct 28 2012, Ion Gaztañaga <> wrote:

> Best,
> Ion
> El 27/10/2012 0:53, Dave Abrahams escribió:
>> 4. This sentence doesn't make any sense to me; it needs clarification.
>> I would make a suggestion, but, well, I don't understand what you're
>> trying to say
>> The last one has the same behaviour as std::uninitialized_copy
>> but since several standand library implementations don't play
>> very well with move_iterators, this version is a portable
>> version for those willing to use move iterators.
> 4. Using move iterator with C++03 compilers lead to compile
> errors. Some MSVC versions use a "_Construct" function that wraps
> placement new. And that funcion takes the argument as a const
> reference.
> template<class _T1, class _T2> inline
> void _Construct(_T1 *_Ptr, const _T2& _Val)
> {
> new (_Ptr) _T1(_Val);
> }
> then the copy constructor is called instead of the move constructor,
> making std::unitialized_copy unusable for move-only
> types. boost::unitialized_copy just tries to avoid this problem so
> that we can write portable code for C++03+Boost.Move and C++11
> compilers. Any suggestion is welcome.

That doesn't explain the sentence, I'm afraid. For example, what does
move_iterator have to do with any of this? It sounds like you're
probably exposing implementation details by mentioning it at all, and if
you *did* implement an algorithm by using move_iterator with a standard
algorithm, you should change that, because you have no right to expect
it to work even in C++11.

>> 5. The section on constructor forwarding seems to imply that
>> constructors are the only thing that will be forwarded, when of
>> course that's not the case.

> 5. I know, but I couldn't find a generic solution for perfect
> forwarding and forwarding for constructors were an important use case,
> specially to implement containers with move semantics for C++03
> compilers. Open to suggestions and changes.

I don't see why your solution for constructor forwarding couldn't apply
equally well everywhere (since it doesn't really do anything other than
pass-by-T const& AFAICT).

>> 6. These sentences don't make sense to me together. They have no
>> obvious connection to one another. To which limitations are you
>> referring?
>> Fortunately, most constructors take arguments by value, by
>> const-reference or by rvalue reference. If these limitations are
>> accepted, the forwarding emulation of a N-argument case requires
>> just N overloads. This library makes this emulation easy with
>> the help of BOOST_FWD_REF and boost::forward
>> As far as I can tell from the implementation, BOOST_FWD_REF just
>> generates a const& in emulation mode, which isn't much of an
>> emulation at all.
> 6. If you limit yourself to constructors taking const references or
> rvalue references (that if you avoid non-const reference or const
> rvalue reference arguments in constructors)

This doesn't make any sense to me either. Just in case our wires are
crossed on this part: arguments are what you pass to functions. They are
lvalues, glvalues, xvalues, rvalues and prvalues. Parameters are what a
function receives; they can be references.

> then this approach works reasonably well. You only need to write N
> overloads to implement emplace functions (as we have no variadic
> templates):
> emplace();
> template<class Arg1>
> emplace(BOOST_FWD_REF(Arg1) arg1)
> template<class Arg1, class Arg2>
> emplace(BOOST_FWD_REF(Arg2) arg2)
> //...
> Just as you need to implement emplace for compilers with rvalue
> references but no variadic templates (like recent MSVC versions)
> emplace();
> template<class Arg1>
> emplace(Arg1 && arg1)
> template<class Arg1, class Arg2>
> emplace(Arg2 &&arg1, Arg2 &&arg2)
> //...
> Catching by const T & works because it catches also rv<T> types, that
> are treated specially by move() and forward() emulation functions to
> emulate forwarding.

I don't see why this wouldn't "work" just as well for non-constructors,
provided you're willing to accept the same limitations on their
parameter types in C++03.

Dave Abrahams
BoostPro Computing                  Software Development        Training             Clang/LLVM/EDG Compilers  C++  Boost

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