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