Re: [boost] [range] fat iterators?

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

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.

I'm open to making similar changes once I've established there is a
real benefit for each case we propose to make the change. I find it
hard to imagine that performance-sensitive code would not be using
custom stream implementations to improve performance. I therefore
wonder how much real world benefit the work would provide.

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

This is definitely something that needs to be added. The challenge is
merely finding sufficient time to do so.

>
> Is it time for Boost.Range 3.0?

I guess that all depends on what Boost.Range 3.0 is. Is the current
Boost.Range so horribly broken that it requires replacement? I think
it probably needs some significant addition, but don't think that the
current facilities are a barrier to progress. Therefore I'm not
currently of the view that we need to throw away and start again. I'm
open to argument on this matter. I think there is a need to fix a
number of trac issues with Boost.Range and to extend the library to
use C++11 to fix some of the lifetime issues. It would be optimal if
there was sufficient time to start work on new range primitives. I am
not, despite my best intentions, able to dedicate sufficient time to
make much progress in the next few months. I'm open to accept help.

>
>  [1]: http://ericniebler.com/2013/11/07/input-iterators-vs-input-ranges
>
> --
> Eric Niebler
> Boost.org
> http://www.boost.org
>

Neil Groves