On Fri, Jul 4, 2008 at 6:09 PM, Mathias Gaunard <mathias.gaunard@ens-lyon.org> wrote:
Finding algorithms (find, find_if, max_element, and others) usually return an iterator to the found position, or the past-the-end iterator.
While enough, it can be quite annoying when used with range adaptors and the like.
Imagine something like this:
auto r = some_range | some adapters...; auto it = max_element(r, comparison_function); if(it != end(r)) { do_something; }
Without auto, it is simply unusable.
If such algorithms returned the range [found, end), we would be able to write:
if(!empty(max_element(some_range | some adapters..., comparison_function)) { do_something; }
Particularly, I find it practical to use it with a function like that: optional<typename range_value<Range>::type> deref_opt(const Range& r) { typedef typename range_value<Range>::type T; return empty(r) ? optional<T>() : optional<T>(*begin(r)); }
or like that: typename range_value<Range>::type deref_def(const Range& r) { typedef typename range_value<Range>::type T; return empty(r) ? T() : *begin(r); }
For compatibility, maybe returning a range type that implicitly converts to the beginning iterator could work.
I do not think it is necessary. One can always apply begin to find the desired iterator.
Do people think this is a good idea?
Agree 100%. I had a similar idea in the past. But what should lower_bound and upper_bound return? -- gpd