Re: [Boost-users] Extending boost::function for mathematics?

Subject: Re: [Boost-users] Extending boost::function for mathematics?
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2009-01-25 14:39:29

On Sun, Jan 25, 2009 at 10:41 AM, Jesse Perla <jesseperla_at_[hidden]> wrote:
> Question 1: Based on your template, how do I forward a function to the
> boost::function's operator() in this wrapper?  Why might we want to do this?
>  Because we are trying to implement a concept with operator() and
> .gradient(..) with a function wrapper here.

Do you require that a math_function object be callable?

I think you're complicating things by defining operator() and
.gradient(). From what I'm reading, I'd rather have operations like
gradient(), derivative(), etc. return boost::function objects. My
rationale is that code that just needs to refer to a function and call
it shouldn't be coupled with math_function.

Also, it makes sense to apply operations like .gradient on a
boost::function as well. For this, you could define conversion from
boost::function to math_function and then call a member function, but
can't these operations be namespace-scope overloads? Then you can
overload them for boost::function as well as math_function.

> 1) Everyone is using dynamic polymorphism for these overloading a virtual
> operator() and some type of gradient/jacobian... I assume this is because
> there is no agreed upon concept for functions objects with gradients...  In
> reality, none of these seem to require dynamic polymorphism.

Boost::function implements its own dynamic dispatching machinery, so
boost::function calls would rarely, if ever, be inlined. I'm
contradicting myself here, but this might be a good enough reason for
you to not use boost::function at all in your framework, and only
define a separate module to convert to boost::function for interfacing
with 3rd party code unaware of math_function.

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode