Re: [boost] Constant iterator of Single Pass Range

Subject: Re: [boost] Constant iterator of Single Pass Range
From: Neil Groves (neil_at_[hidden])
Date: 2014-05-06 16:33:23

On Tue, May 6, 2014 at 8:59 PM, Karsten Ahnert <
karsten.ahnert_at_[hidden]> wrote:

> > All containers are at least forward ranges, not merely single pass ones.
> > Since iterating a forward range does not change it, there is no problem
> > for it
> > to have a `const` `begin()` and `end()` methods (returning const
> > iterators).
> >
> > What I had issue with is single pass range. Consider something that
> behaves
> > like `std::istream`. The `std::istream_iterator` can be only constructed
> > from
> > non-const reference to `std::istream`, because the
> > `std::istream_iterator::operator++` (and the constructor itself) call the
> > `std::istream::operator>>`, which is non-const.
>
> I have exactly the same problem. The iterator approach to treat the
> range as a pair of iterators is not sufficient for me, since it bloats
> the last iterator. I would like to store all informations in the range
> and just pass pointers to the range to the iterators, like Erik Niebler
> explains in his posts single pass ranges.
>
>
There is much merit in having state in a range rather than in bloated
iterators. It is much more general than just the "last" iterator. It is
always horrible to see the predicates and functors held in iterators. It is
not a panacea however for the lifetime issues. If applied universally state
in the ranges would introduce a lot more lifetime issues. Currently many
scenarios work with ranges that die before the end of an expression because
the iterators are copied outside of the adaptor expressions therefore the
iterators are copied into a new range. It is possible to imagine various
mechanisms for passing ownership of ranges or mandating shallow copying,
but these all work less consistently with standard containers. It is not
the case that one solution is obviously always better than the other.

I have done extensive performance measurements upon various arrangements of
having data in iterators versus ranges. I have been surprised how many
times a bloated iterator outperforms the indirection to a separate range
object. The performance impact varies between processor architectures and
of course the size of the iterator and range. I am not allowed to publish
my results due to this being under an NDA. I therefore don't expect my
assertion to be taken as fact. I encourage experimentation.

I am working on Range primitives that are as interoperable as possible with
existing code.

I completely agree that the bloat is suboptimal, but the solution is
nothing like as simple as simple having iterators point to ranges.

>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>