Re: [boost] [range] fat iterators?

Subject: Re: [boost] [range] fat iterators?
From: Thorsten Ottosen (thorsten.ottosen_at_[hidden])
Date: 2013-11-07 14:29:26

On 07-11-2013 15:52, Eric Niebler wrote:
> 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

[snip]

Historical note:

Some years ago, one of the adaptors I wrote returned a range object 
where the iterators kept a reference to the range. I can't remember if 
Neil replaced it or if its still in use.

It had obvious life-time issues if the iterator was extracted from a 
locally constructed range, but I thought 99.9% of all use would be in
loops and with range adapters.

So, as others have pointed out, do we want a design where iterators 
can't outlive the range, even when the range is constructed from, say,
a vector that is kept alive?

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

It seems bad.

FWIW, I'd be happy with a range library that required the range to be 
kept alive as long as the iterator.

Remark on your article: did you benchmark your new design in terms of 
speed and size?

regards

-Thorsten