Re: [boost] Finding algorithms returning ranges?

From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2008-07-04 12:36:53

On Fri, Jul 4, 2008 at 6:09 PM, Mathias Gaunard
<mathias.gaunard_at_[hidden]> 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