Re: [Quantlib-dev] Feedback requests

[Ferdinando A. <na...@am...>]

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