Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2006-02-02 11:57:52


Thorsten Ottosen <tottosen_at_[hidden]> 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

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk