Re: [boost] [Range] initial feedback on return values of algorithms

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