Thanks Rob for bringing the thread back to life, I missed it somehow. On May 23, 2004, at 6:06 AM, Gennadiy Rozental wrote:
I added several algorithms that extent STL algorithms set. I use them in my Boost.Test development. But since they seems to be generic and IMO should be present in STL I propose to push them in boost/algorithm.hpp (or under boost/algorithm). I remember there was a discussion already about these algorithms.
Yes, I like them. I'm sure the rationale has been discussed, and if you make this into a mini-boost library, you'll have to add this to a page. My 2 cents (sorry if this rehashes): 1. The reason std::mismatch does not have a last2 argument is for efficiency, but it presupposes knowing the range length (or at least knowing which one is longer, in order to pass it as first argument). At the cost of one extra comparison per element, you get rid of that requirement and of the occasional reordering of the arguments. 2. One can get find_first_not_of by using find_first_of with std::not2(pred), but your version is more readable and also cuts down on the includes. 3. BTW, since you're using std::bind1st, you should include <functional> With two small web pages of documentation (one for mismatch, and one for find_first_of variants), in the manner of the other boost libraries (including rationale, etc.) I'd heartily support the addition to boost/algorithm/ Now, I'd rather this isn't called a Boost.algorithms library, because there are more that will come in the same vein (already minmax and minmax_element are also separate headers and fill in the same purpose: new algorithms to add to the STL; also I sorely miss is_sorted which was removed from the standard). I'd rather have them in separate headers mismatch.hpp and find_first_of.hpp (since those are extensions of). We can always have a single header algorithm.hpp that includes all those and more as they are submitted. Finally, these little algorithms are barely a library. There was an idea of mini-reviews tossed around. This wouldn't include range / container traits (as Thorsten Ottosen or John Torjo are doing) since it's a much bigger scope, but for one or two functions, a single header, it seems an overkill to have a review. Can we have an Algorithms Review Manager under the Review Manager (as he see fits to forward requests) for the subspace boost::algorithm? I'd volunteer as one if no one else. My two cents, -- Herve'