Re: [boost] [range] fat iterators?

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