search/search_n vs find/find_if

[Chris Jefferson]

Paolo Carlini wrote:
> Paolo Carlini wrote:
> 
>> Can you see anything wrong with calling find_if, instead? Actually, 
>> first blush, I don't understand why find_if was not exploited also in 
>> the original HP/SGI code...
> 
> 
> In order to implement this, bind2nd is needed, apparently, but I cannot 
> see anything wrong...
> 

I had been thinking about this, in particular I'd thought about 
delegating find to find_if, and in general mapping between those 
functions which accept a parameter and those which accept a function 
predicate by something like (note: not actual C++ code!)

template<typename T>
struct __equalobject
{
   T& __obj;
   __equalobject(T& __inobj) : __obj(__inobj)
   {}
   bool operator()(T& __inobj)
   { return __obj == __inobj; }
};

As I imagine that such a class should be optimised away. There are a few 
pairs like find/find_if with this kind of behaviour. While -O2 on x86 
optimises down to what you would expect, I didn't have time to check 
others. Also as find is so small I wasn't sure it was worth the effort 
of delegating it to find_if.

On the unrolling issue, both linux-x86 and darwin, the automatic 
unrolling gets within about 10% to 15% of the unrolled code. However for 
at least 4.0 I would be tempted to leave the manual unrolling, as 
removing it just to decrease speed by 10% seems a little pointless :)

Chris