From: Hervé Brönnimann (hbr_at_[hidden])
Date: 2004-07-23 09:24:16
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
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
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,
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk