Re: [boost] [range][algorithm] Looking for STL adaptations

From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2007-11-19 17:03:59

On Nov 19, 2007 10:37 PM, Eric Niebler <eric_at_[hidden]> wrote:
> Mat Marcus wrote:
> > On Nov 19, 2007 1:01 AM, Dean Michael Berris <mikhailberis_at_[hidden]> wrote:
> >
> >> * Boost.Range friendly versions of the STL algorithms
> >
> > The Adobe Source Library's range/bind-friendly versions of the
> > standard algorithms might also be of some use to you:
> > <http://opensource.adobe.com/group__stl__algorithm.html>
>
> Interesting, Adobe stayed away from output ranges, too. Also interesting
> that the algos that take 2 input sequences (e.g., transform) take a
> range and an iterator instead of two ranges. That's another thorny
> issue. I went the other way, I think. Does Adobe has a design rational
> for these algos?

I've gone too for the route of taking two ranges instead of a range
and an iterator.
My rationale was that it is much easier to compose algorithm
invocations this way.

Also I do bound checking on *both* sequences, not only the first (i.e.
i iterate 'till the end of the
shorter sequence), If you do not bound checks both sequences, taking a range
as second parameter might be misleading.

Finally, I didn't implement the two parameter transform. I use the
single parameter
one composed with zip (which, unlike boost::zip_iterator, stops at the
end of the smaller sequence).
I only provide algorithms that take two sequences if I have to iterate
on the sequences at different speed,
like in std::merge or in a relational join.

BTW, I've been wondering if algorithms that return a single iterator,
should return instead a range:
for example upper_bound should return [first, found), lower_bound
should return [found, end) and equal_range
the intersection of the two i.e. [lower_found, upper_found).

--
gpd