«

In generic programming, static member functions and functors seem to
be very useful. I've noticed that some libraries take the approach of
using templated static member functions to provide generic
functionality, while others use functors. Take for example the
std::string char_traits class. Here, a static member "eq" is defined
to serve as a generic binary comparison function.

My implementation defines it as;

static bool eq(const char_type& c1, const char_type& c2) { return c1
== c2; }

An alternative would be to define eq as a functor, like:

struct eq {
bool operator() (const char_type c1, const char_type c2) { return
c1 == c2; }
}

The major difference, of course, is that the second case requires you
to instantiate the object. I originally thought that there wasn't
much difference, in terms of the actual assembly code generated,
between these two options. But benchmarking tests I've conduct show
that using an instantiated object is almost always faster than using a
static member function. I would have actually thought the opposite
would be true, because with an instantiated object you have the slight
additional overhead of constructing the object, whereas a static
member function is just like calling a global function.

But it seems that instantiated objects outperform static member
functions by a significant amount. My question is, is there some
inherent reason for this, or is this likely to be different from
compiler to compiler? Perhaps static member functions can't be
inlined.

<> wrote in message...
>
> An alternative would be to define eq as a functor, like:
>
> struct eq {
> bool operator() (const char_type c1, const char_type c2) { return
> c1 == c2; }
> }
>
> The major difference, of course, is that the second case requires you
> to ** instantiate the object. **

See if this will compile for you.

// #includes here <cstdlib>, <iostream>, <vector>, <algorithm>,etc.

struct MyRand{
int operator()(){ return std::rand() % 100;}
};

int main(){
std::vector<int> vLf;
std::generate_n( std::back_inserter( vLf ), 1000, MyRand() );
// or is that what you meant by 'instantiate'

std::vector<int>::const_iterator it =
std::max_element(vLf.begin(), vLf.end());
std::cout<<"vector<int> vLf.size()"<<vLf.size()
<<" The largest element is "<<*it<<std::endl;
return 0;
} // main()

Maybe I mis-understood.
--
Bob R
POVrookie

Hi!

schrieb:
> But it seems that instantiated objects outperform static member
> functions by a significant amount. My question is, is there some
> inherent reason for this, or is this likely to be different from
> compiler to compiler? Perhaps static member functions can't be
> inlined.

When passing a (static) function to i.e. std::for_each, you get an
instantiation of for_each, which takes a function pointer as an
argument. So each element is processed by calling a function through a
pointer.

When passing a class instance (a functor) to std::for_each, you get an
instantiation for just that specific class. Each element is process by
an inlined operator().

Usually the compiler does not optimize the (const) function pointer. It
might do so, however. That's why small functors outperform the static
function.

Frank

On Aug 14, 1:32 pm, chsal...@gmail.com wrote:

> But it seems that instantiated objects outperform static member
> functions by a significant amount. My question is, is there some
> inherent reason for this, or is this likely to be different from
> compiler to compiler? Perhaps static member functions can't be
> inlined.

Usually small functors like that can be inlined and therefore generate
more efficient code. If your functor had state and your function used
it for something fairly complicated, you might not see such an
improvement, but a vast majority of the time, you will.

joe