Subject: Re: [boost] [range] adaptors vs. rvalue to lvalue& binding
From: Dave Abrahams (dave_at_[hidden])
Date: 2012-03-23 23:35:33
on Fri Mar 23 2012, Arno SchÃ¶dl <aschoedl-AT-think-cell.com> wrote:
>> - make adaptor expressions return const rvalues. The const rvalues will
>> bind to T& arguments (where T is a template parameter) by deducing T
>> to be const.
>> - make even the const_iterators for such adaptors mutable (writable)
>> This accurately reflects the fact that such adaptors don't own their values.
> If boost::sort is supposed to be chainable (which seems a good idea),
> then let's not start with adaptors. We already need a solution for
> boost::sort( std::vector() );
You can't pass a std::vector() rvalue to any other mutating function.
std::swap(std::vector<int>(), std::vector<int>()); // ERROR
> If the solution is
> template<typename Range>
> boost::sort( Range && );
I think the interesting question is really: what should boost::sort
For example, it *could* return an adaptor that holds a permutation
vector and sorts it lazily. Then you could slice the first ten elements
off the sorted result and it would only have to do a partial_sort in the
implementation. Or it could return an adaptor that holds a permutation
vector and sorts it eagerly. Or, it could return a brand new container.
Or, it could sort in-place and return and return a const pair of mutable
> then in
> boost::sort( boost::adaptors::reverse( std::vector() ) );
> reverse should probably derive mutable iterators from mutable rvalues,
I don't know what you mean by "derive mutable iterators from mutable
rvalues." If you mean that you ought to be able to get a mutable
iterator from a mutable rvalue... IMO that sort of goes against the
grain of the type system.
std::vector<int>& v = std::vector<int>(); // Error
std::vector<int> const& v = std::vector<int>(); // OK
-- Dave Abrahams BoostPro Computing http://www.boostpro.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk