Posted by
Chris Kenyon-2 on
URL: http://quantlib.414.s1.nabble.com/solvers-in-Instruments-why-nested-classes-rather-than-adapter-binder-tp9289.html
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.
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev