[Quantlib-dev] solvers in Instruments - why nested classes rather than adapter+binder?

[Chris K. <chr...@ya...>]

Hi,

I have a question about use of solvers, e.g. in Instruments & Engines.  In classes such as CapFloor a nested class in the Instrument is used to provide a function to a solver by overloading the  () operator (see capfloor.hpp & capfloor.cpp).   However, the same result can be achieved by using an ordinary method (no overloading) together with a binder and an adapter (see 18.4.4 of C++ 3rd edition), plus a bit of boost, e.g.:

----------------------------------------
#include "boost/function.hpp"
#include <functional>

boost::function1<Real, Real> f;
f = std::bind1st( std::mem_fun( &className::methodName ),  &(*this) );
Brent solver;    
Real resultX = solver.solve(f, accuracy, guess, minX, maxX);
----------------------------------------

No changes are required in the solver code.  (Of course you need to set up methodName to return the difference between the targetValue and the value generated by the method call.)  This seems to avoid a lot of the overhead of creating a nested class at the cost of using a potentially obscure (but supported) piece of C++ generics, plus boost which is already used.

So why go with embedded classes?  What was the rational?

Very curiously,

CMK

p.s. another potentially cleaner alternative, local classes, is not supported by most compilers.