Re: [boost] [range] fat iterators?

Subject: Re: [boost] [range] fat iterators?
From: Eric Niebler (eniebler_at_[hidden])
Date: 2013-11-12 12:19:05

On 11/12/2013 8:38 AM, Thorsten Ottosen wrote:
> On 12-11-2013 16:41, Eric Niebler wrote:
> 
>> I've now built a filter_range, transform_range, and an istream_range in
>> this vein. Initial results are looking promising, but I haven't
>> benchmarked performance, yet. A commenter on my blog claims to have
>> benchmarked perf of istream_range, with good results, which is
>> encouraging.
>>
>> If anybody wants to take a peek, you can find the code here:
>>
>> https://github.com/ericniebler/range-v3
>>
>> I'm making no effort to maintain source compatibility, going instead
>> with the design that seems right to me for C++11.
> 
> Good. I totally agree that r-value refs change things completely.
> 
> Some small comments (applies for transform_range as well):
> 
> A. For filter_range, you should inherit from the predicate if possible
> to enable EBO. I don't know if lambdas complicate this?

I should use EBO, but that's not the right place for it. It adds a bunch
of associated namespaces to the filter_range type. Rather, the predicate
and the adapted range should be in a compressed pair. I have this
working locally already. The space savings are worth it: a filtered,
filtered, transformed range goes from 24 bytes to 16.

> B. For the constructor
> 
>    filter_range(Rng && rng, Pred pred)
> 
> then maybe it would be beneficial that empty predicates are constructed via
> 
>    filter_range(Rng && rng)
> 
> ? I guess it needs benchmarking though, but the compiler will have to
> elide a series of moves vs. default construct an empty class.

I don't think this is worth it. I can't imaging any compiler having a
hard time eliminating empty moves. There's nothing to move!

> C. I can't quite figure out your use of filterer::filterer1. Do you
> really have to store the predicate here also?

filterer1 is the object returned by "filter" in an expression like this:

    vec | filter(pred)

So yes, it needs to store the pred. One of my breaking changes is to
allow the "filter" name to be reused such that these two are equivalent:

    vec | filter(pred)
    filter(vec, pred)

I want this. I never liked "filtered" or the adaptors namespace.

-- 
Eric Niebler
Boost.org
http://www.boost.org