Re: [boost] [range] fat iterators?

Subject: Re: [boost] [range] fat iterators?
From: Neil Groves (neil_at_[hidden])
Date: 2013-11-07 09:49:46

On Thu, Nov 7, 2013 at 2:20 PM, Eric Niebler <eniebler_at_[hidden]> wrote:
> I wrote an article describing the "fat" std::istream_iterator and how it
> can be slimmed down by giving it an owning istream_range[1]. I see there
> already is an istream_range in Boost.Range, but it suffers from the
> fat-iterator problem I describe there. Is there a compelling reason why
> the implementation of boost::istream_range shouldn't be changed to be
> more like the one I describe? Also, as a commented pointed out, the same
> problem exists for the filtered range and the transformed range, too.

While I like the advantages of pushing state into the range this adds
a requirement for the range to outlive the iterators. This change I
think inevitably leads to backward compatibility problems to poorer
interoperation with existing iterator-based interfaces. For cases
where we can deprecate iterators and add the lifetime guarantee I see
the appeal.

In the case of the filter adapter reusing the filter_iterator this was
to allow interoperation with iterator-only algorithms. I didn't want
to impose the constraint of having to have a range outlive the
iterator. There is additionally advantage in locality of data for
small predicates (which is my typical use case). I can see that if we
could solve the lifetime issues that we could do better by having a
mechanism to use the local solution where it is optimal and store the
predicate somewhere else when it is sufficiently large or expensive to
copy. This can be done now by using a wrapper around a reference
counted pointer implementation of the predicate. This is close to
optimal without breaking backward compatibility. Indeed if we solve
the range lifetime issue we end up with similarly expensive solutions
I think.

>
> The trick, of course, will be keeping intermediate temporary ranges
> alive long enough to avoid lifetime issues when we chain adaptors and
> assign the result to a local variable. I think a range library that's
> sensitive to the value category of range objects and makes copies of
> rvalue ranges would solve this problem. Thoughts?
>

I like the idea. I can't see a solution that leads to better
performance than is obtainable currently. This is likely a failure of
my imagination!

> Is it time for Boost.Range 3.0?
>
>  [1]: http://ericniebler.com/2013/11/07/input-iterators-vs-input-ranges
>
> --
> Eric Niebler
> Boost.org
> http://www.boost.org

Neil Groves