|
From: Luigi B. <lui...@gm...> - 2021-04-08 13:37:41
|
Hello David,
I'd prefer not to do that in the library. It would mean not only
maintaining the factory, but also the whole set of different
day-counter names that people might have in their existing DB because
they're getting data from Reuters or Bloomberg or whatever provider they're
using.
Luigi
On Wed, Apr 7, 2021 at 7:40 PM <da...@el...> wrote:
> Hi,
>
> This may be something that has been asked before, but I am trying to
> rebuild various DayCounters (and indeed other Enums/classes) from a
> string-based name in C++. My goal is to store the configurations needed to
> build a QL bond in an SQL database (eg if I want to build a Belgian spline
> curve, from a defined list of bond ISINs).
>
> In Python, with its run-time type discovery, I can save the string
> representation of the class or enum into the database, and get the object
> back using eval(). However that isn’t much help for when/if I migrate the
> code to C++. I’d much prefer to use the string-based name, as in QuantLibXL
> (see QuantLibXL: Enumerations
> <https://www.quantlib.org/quantlibxl/enums.html#enum_type_11> ) which has
> the added benefit that I can use the same definitions in Excel.
>
>
>
> It is simple enough to write a DayCounterFactory class in C++, build a map
> of {name,instance of QL class), and get back a DayCounter object of the
> correct type. However, I run the risk of being out of sync with any changes
> made in QuantLib (eg new enums).
>
> Is there any chance of putting this factory into QuantLib itself, and
> hence maintaining it along with the rest of the project? This may have been
> asked before, and rejected for sound conceptual reasons of which I am
> unaware!
>
>
>
> Best wishes,
>
>
>
> David Sansom
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>
|