Re: [boost] boost/test/detail/algorithm.hpp: request for promotion and/or fast review

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
> 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'