Adam Wulkiewicz wrote:
Hi,
Neil Groves wrote:
iterator_range already has front() and back() functions. These are not part of the Range Concept since we want to be able to model them non-intrusively. The iterator_range and sub_range classes can be used to wrap other iterator pairs or ranges and provide most of the member functions that you are suggesting.
Thanks for the tip. However I rather see those functions as algorithms, not a part of the Concept. They musn't be modeled intrusively, just like any other Boost.Range algorithm.
So in the case of iterator_range the use case would look like this:
boost::make_iterator_range(range).front(); boost::make_iterator_range(range).back(); boost::make_iterator_range(range)[index];
I'd say it's less intuitive/readable/convenient than:
boost::front(range); boost::back(range); boost::at(range); Of course this should be:
boost::at(range, index);
And the readability is what I wanted to achieve but ok, the functionality is there. And this way the implementation of operator[] is straightforward. Still, I prefer my way :)
Regards, Adam