Re: [boost] [range] fat iterators?

Subject: Re: [boost] [range] fat iterators?
From: Eric Niebler (eniebler_at_[hidden])
Date: 2013-11-12 10:35:47

On 11/12/2013 5:22 AM, Dave Abrahams wrote:
> Eric Niebler <eniebler_at_[hidden]> writes:
> 
>> 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
> 
> Seems like we've been in this territory before...
> http://boost.2283326.n4.nabble.com/lifetime-of-ranges-vs-iterators-td2650349i20.html

That discussion most certainly would have been different had rvalue refs
been around. We're having that discussion now...

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