Boost logo

Boost :

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

On 11/12/2013 8:21 AM, Evgeny Panasyuk wrote:
> 12.11.2013 19:41, Eric Niebler:
>> I've now built a filter_range, transform_range, and an
>> istream_range in this vein. Initial results are looking promising,
>> but I haven't benchmarked performance, yet. A commenter on my blog
>> claims to have benchmarked perf of istream_range, with good
>> results, which is encouraging.
> While new "slim" istream_range is faster than version with "fat"
> iterators, it is still not the fastest possible. In particular, it
> does two comparisons per cycle iteration: one is "!rng_->next()", and
> another is comparison of iterators, like "it != last".

The commenter on my blog claims this extra check is optimized away by a
smart compiler like gcc. He says[^1]:

> Your istream_range solution is pretty awesome. I tested the generated
> assembly on and compared it to plain old while()
> looping and D-style iteration
> Incredibly, the conditional nulling-out inside your iterator
> increment() appears to be optimized away altogether. It’s very
> surprising that the compiler can prove that a nullptr value will be
> compared to the other nullptr value lurking inside the end()
> iterator. Essentially the same assembly is generated for all 3
> approaches.

It remains to be seen how well compilers can optimized several stacked
range adapters, but at least in the simple cases we don't have to accept


Eric Niebler

Boost list run by bdawes at, gregod at, cpdaniel at, john at