[Quantlib-dev] Why doesn't there exist a QuantLib Leg Hierachy?

[Sebastian P. <Seb...@gm...>]

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.