[boost] [range] fat iterators?

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

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.

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?

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