On Nov 19, 2007 10:37 PM, Eric Niebler <eric@boost-consulting.com> wrote:
Mat Marcus wrote:
On Nov 19, 2007 1:01 AM, Dean Michael Berris <mikhailberis@gmail.com> 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