Hi, On Thu, Feb 26, 2009 at 2:04 PM, Thorsten Ottosen < thorsten.ottosen@dezide.com> 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