On Sun, Jan 25, 2009 at 10:41 AM, Jesse Perla
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