Re: [boost] [range] fat iterators?

On 11/7/2013 3:31 PM, Neil Groves wrote:

On Thu, Nov 7, 2013 at 2:20 PM, Eric Niebler 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