Boost logo

Boost :

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

> Hello,
>> - 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)
>> iterators
>> 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() );

Do we?

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

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