4 Jul 18:09
Finding algorithms returning ranges?
Mathias Gaunard <mathias.gaunard <at> ens-lyon.org>
2008-07-04 16:09:57 GMT
2008-07-04 16:09:57 GMT
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.
Do people think this is a good idea?
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RSS Feed