Thorsten Ottosen <tottosen@dezide.com> writes:
Dear all,
The plan is to include range-based overloads of std algorithms in the next boost.range.
We have several options for specifying the return type of functions that normally return an iterator that I would like your feedback on.
1. leave the return type as it is.
2. return an iterator_range describing the range [found,end) this allows us to do stuff like
namespace br = boost::ranges; br::erase( rng, br::unique(rng) );
3. inspired by John Torjo's range lib, provide a whole list of possible return values:
std::vector<int> v; namespace br = boost::ranges; br::unique(v); br::unique<br::return_found>(v); br::unique<br::return_next>(v); br::unique<br::return_prior>(v); br::unique<br::return_begin_found>(v); br::unique<br::return_begin_next>(v); br::unique<br::return_begin_prior>(v); br::unique<br::return_found_end>(v); br::unique<br::return_next_end>(v); br::unique<br::return_prior_end>(v);
2 is the answer for me.
the default would be the range [found,end), but the you can pick different slices or simply iterators. In the above scheme, "found" is the iterator normally returnes by the algorithm, "next" means boost::next(found) and "prior" means boost::prior(found).
And that works for ranges without bidirectional iterators, e.g. slist?
The advantage of the latter approach is
- flexibility/power - safety (we can tjeck that next(found) and prior(found) stays in range)
The disadvantage is that it will require twice as many overloads in C++03 (since we can't put defaults template arguments in function templates).
And it's complex. I'm wary of introducing any such complexity without a strong catalog of use cases. -- Dave Abrahams Boost Consulting www.boost-consulting.com