http://quantlib.414.s1.nabble.com/Why-doesn-t-there-exist-a-QuantLib-Leg-Hierachy-tp9632p9633.html
I can't speak for the devs, but one issue with your suggestion as written is that it is generally considered a Bad Idea to derive from STL containers (no virtual destructors, e.g.). More to the point, a Leg should properly be a collection of (possibly heterogeneous) cash flows; the "kind" or "type" of leg you are dealing with is determined by properties of the cash flows that it contains. Any other properties you might like a Leg to have depend on its context, i.e., to the instrument (swap in your case) to which it belongs. So really, the design decision was to split the work between the CashFlow hierarchy and the Instrument hierarchy. There is no need to make the Leg class "smarter".
In QuantLibXL, can create new (possibly complicated) constructors (qlIborLeg and qlFixedRateLeg, say) which stores the type of leg you want in the object repository. You can then plug these Leg objects into the IborLeg and FixedRateLeg slots of your swap constructor.
> Date: Fri, 16 Nov 2012 09:27:37 -0800
> From:
[hidden email]
> To:
[hidden email]
> Subject: [Quantlib-dev] Why doesn't there exist a QuantLib Leg Hierachy?
>
>
> Hello,
>
> I've tried to "reconstruct" a QuantLib swap object in another environment
> (QuantLib Excel). The idea was to use the swap properties (including private
> ones if necessary) to construct adequate ObjectHandler::ValueObjects, which
> can be used to "design" the objects in an excel workbook.
>
> After some coding I've recognized that this seems to be impossible (or at
> least harder than expected) in the current QuantLib environment. The reason
> is that there is no QuantLib Leg Hierachy in the library. Each Leg is just a
> vector of cashflow pointers and it is hard to differentiate if a leg was
> intended to be an iborleg, a fixedrateleg etc.
> For example you use the "helper class" fixedrateleg to (temporarely) create
> a fixedrateleg. As soon, as you pass it to a swap this fixedrateleg is just
> casted to a vector of cashflowpointers, loosing the information what it was
> intended to be. I'm wondering why this "design" was choosen.
> I suppose that a structure similar to that:
>
> typedef std::vector<boost::shared_ptr<CashFlow>> Leg;
>
> // concrete FixedRateLeg class
> class FixedRateLeg : public Leg {
> ....
> }
>
> //! helper class building a FixedRateLeg
> class MakeFixedRateLeg {
> // similar to current FixedRateLeg helper class
> // cast operator on new FixedRateLeg Class instead of Leg:
> // operator FixedRateLeg() const;
> }
>
> would be in some circumstances superior to the current structure. This is
> (for example) the way the swap class (with its child vanillaswap) is
> organized. Is there a special reason that this "thing" Leg did not get an
> objecthierachy in QuantLib?
>
> Regards
> Sebastian
>
>
>
> --
> View this message in context:
http://old.nabble.com/Why-doesn%27t-there-exist-a-QuantLib-Leg-Hierachy--tp34689442p34689442.html> Sent from the quantlib-dev mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
>
http://p.sf.net/sfu/zoho_dev2dev_nov> _______________________________________________
> QuantLib-dev mailing list
>
[hidden email]
>
https://lists.sourceforge.net/lists/listinfo/quantlib-dev
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.