Boost logo

Boost :

Subject: Re: [boost] [Move] Documentation Notes/Questions
From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2012-10-28 07:56:11


Thanks for the comments.

1. Thanks, I'll fix it.

2. Thanks, I'll add it to the documentation. I agree that Move
documentation is far from complete.

3. Just because I usually write my own loops (my C programming
backgroud, I guess). I'll change this.

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

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.

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

7. ;-)

Best,

Ion

El 27/10/2012 0:53, Dave Abrahams escribió:
>
> 1. In the docs, "comes in handful" => "comes in handy"
>
> 2. IMO, it's almost irresponsible to advertise move_iterator without
> saying that it's really *only* safe to use when you know
> implementation details of the algorithm or function to which you're
> passing it. In particular, it must not attempt to copy from any
> given position in the sequence more than once.
>
> 3. Why doesn't test_move_inserter use std::copy?
>
> 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.
>
> 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.
>
> 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.
>
> 7. "David Abrahams suggested the use of class rv class": too much class
> :-)
>


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk