Re: [boost] Formal Review: Boost.RangeEx -- Comments from Sean Parent from Adope

Subject: Re: [boost] Formal Review: Boost.RangeEx -- Comments from Sean Parent from Adope
From: Neil Groves (neil_at_[hidden])
Date: 2009-02-26 09:26:04

Hi,

On Thu, Feb 26, 2009 at 2:04 PM, Thorsten Ottosen <
thorsten.ottosen_at_[hidden]> wrote:

> Hi Neil,
>
> Here are some comments from Sean. I think they raises several aspects that
> we shuold discuss.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>
>
>
> Some comments after taking a quick look (sorry, I don't have time for a
> full review) -
>
> Some important range concepts are missing - specifically:
>
> counted range (a range denoted by an iterator and an integer count)
>

This seems very similar to the indexed range adaptor in the current library.

> sentinel range (a range denoted by an iterator and a sentinel, a NTBS is an
> example)
>

I haven't implemented one of these. If I could get one from Adobe that would
be marvelous, otherwise I can write one.

>
> I believe such concepts could also clean up the char* vs. char[] for NTBS
> ambiguities as well as keep cstr library efficiency.
>
> In ASL we've been slowing extending the algorithms for such cases, for
> example, see lower_bound_n.
>
> <http://stlab.adobe.com/lower__bound_8hpp.html>
>
> Also, the range based algorithms in ASL are not just about ranges, we also
> bind function arguments to avoid having to clutter binds in interfaces,
> "find_if(range, &my_type::member)"
>

It seems like this really is a combinatorial explosion. I'd like to take
some time to consider this further.

>
> We've also been extending the algorithms to take key/projection functions.
> For example:
>
> ---
>
> struct my_type {
>    int         member;
>    double     another_member;
> };
>
> //...
>
> my_type a[] = { { 1, 2.5 }, ... };
>
> // sort the array by the first member:
>
> sort(a, less(), &my_type::member);
>
> my_type* i = lower_bound(a, 5, less(), &my_type::member);
>
> ---
>
> In ASL, I believe we get far more bang out these extension then we do out
> of the range extensions.
>
> I haven't looked at the Range.Ex code, but many such libraries refine
> mutating container algorithms such as sort() to call list<>::sort() - I
> object to refining algorithms where the semantics differ (in this case,
> std::sort(list.begin(), list.end()) is identity preserving where
> list<>::sort() is not. I would rather see the introduction of node based
> algorithms, such as sort_nodes() and specialize those for list<>.
>

Yes this would be very good. I share your view about overloading sort().
It's just not going to happen! The current implementation does not overload
sort with differing semantics. Adding new functions such as sort_nodes is
definately the way to go, but hasn't been done yet.

>
> The addition of bounded functions (which take output ranges) would also be
> a nice addition - see copy_bounded as an example:
>
> <http://stlab.adobe.com/group__copy.htm>
>
> If anyone would like to take the code from ASL as a starting point for
> inclusion in boost, they have my permission.
>

I have a preference to use the boost/range/algorithm_ext.hpp where they can
be used, as these have several advantages in terms of performance and
inability to express defective code. However there are of course cases where
we need the other output range types I will definately add better output
range support.

This is very generous. I would be delighted to pilage your library to add
the functionality you have discussed!

> Sean
>

Thank you for taking the time, especially as you are busy, and have
considerable experience with a similar library.

Best wishes,
Neil Groves

>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>