Boost logo

Boost :

Subject: [boost] [Move] Documentation Notes/Questions
From: Dave Abrahams (dave_at_[hidden])
Date: 2012-10-26 18:53:44


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

-- 
Dave Abrahams
BoostPro Computing                  Software Development        Training
http://www.boostpro.com             Clang/LLVM/EDG Compilers  C++  Boost

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