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) sentinel range (a range denoted by an iterator and a sentinel, a NTBS is an example) 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)" 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<>. 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. Sean