Feedback request 2 - Boost

[Luigi Ballabio-2]

Hi all,
     part 2 of 3 in a feedback-request frenzy:

as reported e.g. in <http://www.cuj.com/documents/s=8890/cujexp0310sutter/>
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---but also other nice toys
which we could put to good use. Now, in the most optimistic case, it will
take years before this is fully standardized. However, eventually we'll be
wanting to eighty-six our homegrown solutions and replace them with the
hallowed and standard ones. And honestly, I'd rather do it sooner than
later---hopefully the number of our users will increase and make it more
and more difficult to make such changes.

Hence the question: should we start using boost? 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.)

Let me know what you think.

Later,
        Luigi

[Ferdinando M. Ametrano-3]

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