Re: [boost] [range] fat iterators?

Subject: Re: [boost] [range] fat iterators?
From: Eric Niebler (eniebler_at_[hidden])
Date: 2013-11-07 09:52:26

On 11/7/2013 3:31 PM, Neil Groves wrote:
> 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.

Forget streams. Think of something like this:

  rng | filtered([=](xxx y){ I reference local vars; })

Now you have a pair of filter_iterators, each of which has a copy of the
lambda, and each lambda has a copy of all the local variables the lambda
captures. Copying those iterators makes a copy of all the locals
captured by the lambda. Am I wrong? That's pretty bad.

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

<sigh> I can relate.

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

See the filtered range example above. It's not pretty.

> I think
> it probably needs some significant addition

Addition won't cut it unless you want to drop support for C++98. The
optimal design I'm suggesting requires the ability to detect rvalues
with 100% fidelity. So the current design is as good as it gets for
C++98 users, AFAICS. There needs to be a parallel rvalue-aware range
library for C++11 where virtually all the range and iterator types are
different.

>, 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. 

What new primitives do you have in mind?

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

This is important to me. I'm willing to help if you agree to the
direction I've described.

>>  [1]: http://ericniebler.com/2013/11/07/input-iterators-vs-input-ranges
>>
> 
> Neil Groves

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