Posted by
Ferdinando M. Ametrano-3 on
Oct 14, 2003; 9:33am
URL: http://quantlib.414.s1.nabble.com/Feedback-request-2-Boost-tp10380p10381.html
Boost:
>the powers that be have selected a few features for inclusion in a future
>addendum to the C++ standard, mostly borrowed with minor modifications
>from the Boost library (<
http://www.boost.org>). Most notably, a
>shared_ptr class was accepted which supersedes our Handle [...] should we
>start using boost?
as Luigi knows, I've already advocated the boost usage a few times in
private discussions. boost also includes a unit test framework which might
replace cppunit, in order to limit the external library dependencies.
> I'm not advocating a fast switch---personally I'd make the full
> migration in as much as three releases (one using boost if available and
> falling back to our thing if not, one requiring boost but still providing
> typedefs for the old names, one removing the last traces of our once
> beloved classes.)
I cannot disagree, especially considering that much of the burden of this
transition will be on your shoulder :)
---------------------
Namespaces:
>sub-namespaces such as QuantLib::Instruments or QuantLib::PricingEngines
>tend to get a lot in my way. Have they ever been useful?
QuantLib::Instruments and QuantLib::Pricers are currently guarding against
few name clashes: BinaryOption and BarrierOption comes to mind
> How about ditching them and flattening the thing to the single QuantLib
> namespace?
It's OK for me.
> We can do it in a conservative way in a couple of releases (in the
> first, we flatten the namespace, we leave aliases to the old
> sub-namespaces around so that it's not an error if one uses them, and we
> deprecate them; in the second, we kill them.)
see above :)
-------------
templated lattices:
>Following the thread we had in July about the merits of template code
>against more classical polymorphism, I experimented with some of the code
>for binomial trees and reimplemented it with template techniques. [...]
>
>Have a look, and let me know what you think.
I've realized it is not a 10 minutes task :(
>Now, my dilemma is: on the one hand, the new code is more heavily
>templated and might be more difficult to use [...] On the other hand [...]
>it is 300 % faster.
I think we should take care to present an easy to use interface to our
end-users (me included :)
I'm not against extra complexity in the inner QuantLib code, especially if
it is documented. I mean I would appreciate if you could ease in some way
the burden of understanding such starting points as
class NumericalMethod2 : public Patterns::CuriouslyRecurringTemplate<Impl>
> I have no idea what the savings could be on Windows---frankly, I don't
> even know if the thing compiles :)
It might be worth checking this out before moving to the new template approach
------------------------
Luigi: after the quantlib-dev feedback will you present these issues to the
quantlib-users mailing-list?
ciao -- Nando