Something like:

struct FunctObjBase
{
virtual ~FunctObjBase(){}
virtual double execute(double d) const = 0;
};

struct Helper : FunctObjBase
{
template
Helper(F const & f):
m_f(f){}

virtual double execute(double x){return m_f(0);}

private:
boost::function m_f;
};

Atleast thats what I’d do without evidence/requirements/proof to tell me otherwise.

When we wrote our numerical library, we had a debate between using abstract base classes and templates. My first thought was to use the former, but we ended up going with the latter. I don’t know whether we made the right choice.

Templates provide a form of “duck typing” in that you don’t have to derive your function objects from a particular base class. But using templates has lead to some ugly declarations when there are multiple function objects or nested function objects involved. It has also led to putting more code in .h files and less in .cpp files, which has its own set of pros and cons. I don’t know what I’d do if we started over.

Specifically, the original solution is not entirely unlike:

double
compute(double * a, double * b, double * c, double x)
{
return 1000* (*a) + 100 * (*b) + 10* (*c) + x;
}

Whereas the bind solution works out to approximately:

double
compute(double a, double b, double c, double d)
{
return 1000 * a + 100 * b + 10*c + d;
}

If we want to talk premature optimization, the first example can cause cache misses and all sorts of headache.

I’m interested in that real program of yours!

That smells like premature optimization to me. I would be very careful to measure in a /real/ program first. If you have such a program, I’d be interested.

Also, boost bind is not just for the nutters anymore: TR1 includes boost bind and boost function (of course, in the std namespace…)

Good post John.

To be honest, I really prefer to have the the function class implement an interface or abstract class rather than either of these solutions, but that’s another subject entirely.

I thought maybe Boost was unnecessary, but the standard C++ library only has bind1st and bind2nd, so I guess you do need Boost for a more general bind function.

The problem with your approach is that the constants must be added to the stack every time f(x) is called (bind isn’t cheap to use.) If one is using a zero finder that uses reverse communication, using bind will add significant overhead to the call. By storing the constants internally in the structure, as in the original example, you trade more or less constant heap storage for very dynamic stack storage of the constants. I also like John’s approach because you don’t have to drag boost into the problem.

struct Function
{
double operator()(double a, double b, double c, double x)
{ return 1000 * a + 100 * b + 10*c + x; }
};

double maximum = Maximize(bind(Function(),3,1,4,_1),a,b)

For this example, it is kind of overkill but my general preference is to prefer free functions and boost bind to generate functions