On Tue, May 6, 2014 at 8:59 PM, Karsten Ahnert < karsten.ahnert@googlemail.com> 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