On Mon, May 5, 2014 at 11:03 AM, Jan Hudec
Hello All,
The documentation of [Single Pass Range][1] in Boost.Range says that there should be both `iterator` and `const_iterator` associated types and both const and non-const overloads for `begin` and `end`. However if it is really a single-pass range, I don't see a way to implement a `const_iterator` that would work on `const` reference to the range, because the `operator++` of the iterator involves calling a non-const method of the range.
I think that your statements indicate that you have a misunderstanding about implementing iterators. The word "const" does not refer to the iterator type itself but to the reference type. It is not possible without resort to very perverse use of the "mutable" keyword to implement a const_iterator to refer to any type. Of course, const_iterator is part of every standard container so this is not an idiom that is specific to Boost.Range.
For example the `std::istream_iterator::operator++` calls `std::istream::operator>>`, which is non-const and so there is no `const_istream_iterator`. The `istream_range` cheats around this a little, because the range is a wrapper around the stream, not the stream itself. But when I have similarly behaving class that I can make itself be a range, do I really have to work around this using a wrapper, or can the requirement be relaxed in practice?
I believe that you don't have a problem! A const_iterator can be implemented with non-const member functions. There are examples within the Boost.Range unit test code that show the use of extending Boost.Range for user defined types. These show the various methods for implementing this. There is also documentation that has an example extending via the const and mutable meta-functions here: http://www.boost.org/doc/libs/1_55_0/libs/range/doc/html/range/reference/ext... In the above example the type returned from the meta-function is the same for both the const and mutable versions. If the iterators are acting upon a container then you often don't need to provide either of the range meta-functions for obtaining the iterator since the member typedefs will be sufficient. I typically implement my own container types to simply have the member typedefs and avoid the need to specialise the meta-functions. One would typically extend the meta-functions when the custom range or container does not model standard container Concepts. It might therefore be worth reviewing the rest of the Boost.Range reference section on extending the library.
-- Jan Hudec
If I have misunderstood your problem, or you require any additional help please let me know. Regards, Neil Groves