Re: [boost] [Move] Documentation Notes/Questions

Subject: Re: [boost] [Move] Documentation Notes/Questions
From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2012-10-30 17:34:22

El 30/10/2012 0:56, David Abrahams escribió:

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

Ok. But, isn't move_iterator guaranteed to work for 
[uninitialized_]copy/copy_n algorithms?

For std::copy I read "For each non-negative integer n < (last -first), 
performs *(result + n) = *(first + n).", and "Complexity: Exactly last - 
first assignments". Input Iterator requires "*a convertible to T", and 
move_iterator returns T&&, which is convertible to T. Doesn't this 
guarantee move_iterator works with std::copy?

For uninitialized_copy:

Effects:
for (; first != last; ++result, ++first)
::new (static_cast<void*>(&*result))
typename iterator_traits<ForwardIterator>::value_type(*first);

Doesn't this guarantee move_iterator will always work in C++11 
uninitialized_copy?

If both algorithms are usable with move_iterators, then I think it's 
useful to have a boost implementation that work both in C++03 and C++11 
compilers. I only added uninitialized_copy, but it could be useful also 
for uninitialized_copy_n. I'd need to test if std::copy in supported 
C++03 compilers work with move_iterator.

I agree that this is horribly explained in the documentation.

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

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

Understood, then can  the documentation be improved replacing "most 
constructors take arguments by value" by "most constructors accept their 
parameters by value, const reference or rvalue reference"?

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

Of course. If I remember correctly, during the pre-review and review 
period, I was told that it should be clear that this "portable" 
forwarding was not a general forwarding solution, but it was targeted to 
forward arguments to factories, constructors, and emplace functions. The 
best name I could invent was "constructor forwarding". I'd gladly change 
the name to something better.

As an improvement, it could treat std::/boost::ref as an special case so 
that we could forward arguments to functions taking parameters by 
non-const references.

Best,

Ion