Posted by
Luigi Ballabio on
URL: http://quantlib.414.s1.nabble.com/solvers-in-Instruments-why-nested-classes-rather-than-adapter-binder-tp9289p9290.html
On Tue, 2007-03-20 at 10:49 -0700, Chris Kenyon wrote:
> 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 [...]
>
> So why go with embedded classes? What was the rational?
Historical reasons, I guess. In later versions of the library, the
solve() method was not template, and the function object to be passed
had to inherit from a base class. When we changed solve(), we didn't
bother changing the client code since it worked as it was.
Moreover, the inner class is not so bad. It encapsulates nicely a few
accessory object which otherwise should be kept as data members of the
CapFloor class itself. What we could do, however, is to avoid defining
it as an inner class. We could remove it from the header altogether and
define it in an anonymous namespace in the .cpp file. Did you spot any
other such class in the library?
Later,
Luigi
----------------------------------------
I've finally learned what `upward compatible' means. It means we
get to keep all our old mistakes.
-- Dennie van Tassel
-------------------------------------------------------------------------
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