Re: search/search_n vs find/find_if

[Chris Jefferson <caj at cs dot york dot ac dot uk>]

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