# QuantLib: New Instrument derived from VanillaOption + PricingEngine that must work for both VanillaOption and the derived class

The derived class is a Vanilla Option on a Future and I need to specify the expiry of the underlying future which is in general different (later) than the expiry of the Vanilla Option. I have implemented a couple of PricingEngine that derive from VanillaOption::engine and for the moment their respective calculate() methods assume that the expiry of the future coincides with the expiry of the option.

I plan to proceed as follows:

1. Declare the derived class VanillaOptionFuture as follows: class VanillaOptionFuture : public VanillaOption
2. Define a new type of argument for this class as follows: class VanillaOptionFuture::arguments : public VanillaOption::arguments and add a new field called futureExpiry_.
3. Redefine the method setupArguments for class VanillaOptionFuture in order to call the homonymous method of class VanillaOption plus setting the futureExpiry_ field of the arguments class, which will be passed to the constructor of the class.

Question: I would like to keep my pricing engines working for the general case of a VanillaOption with the default behavior futureExpiry_ = arguments_.exercise->lastDate(). I was thinking on leaving the declarations of my pricing engines as they are and just deal with the two cases directly in the calculate() methods by using boost::dynamic_pointer_cast. Do you think this is the right way to proceed? Thanks for any advice.

It's kind of complicated. I'm afraid QuantLib doesn't have a "right" way to do this.

The short answer is that the way you sketched (inheriting from VanillaOptionFuture::engine) should work. You might not even need a dynamic_cast; if you're passing the engine to a VanillaOptionFuture, it will set the futureExpiry data member, whereas if you're passing the engine to a VanillaOption it will ignore it. Inside calculate, you can just check whether futureExpiry is a null Date().

The longer answer is that the class diagram you're building is a bit shaky. You're starting from

class VanillaOptionFuture : public VanillaOption


which lets you avoid duplication of all the code around data members but, in C++ idioms, is saying "a vanilla option on a future is a particular kind of vanilla option". This lets you avoid a lot of code duplication, so let's go with it, but it can take a reader aback a bit if she's thinking that a vanilla option is an asset option. Anyway, as I said, let's go with it.

The relationship between the corresponding engines, and it is going to be tricky. You didn't say how you plan to implement it, but you need a new argument class, so you also need to define a new VanillaOptionFuture::engine class; you can't just reuse VanillaOption::engine, whose argument class is fixed.

Possibility 1: if you inherit VanillaOptionFuture::engine from VanillaOption::engine, you're saying that an engine for a future option is an engine for an option, which in your case looks right—your engine can price both—but it's not guaranteed in general, since a given engine for futures option might rely on futures data which are not available from plain options.

Possibility 2 is to define VanillaOptionFuture::engine as independent of VanillaOption::engine and sidestep the semantic problem. You can also sidestep the semantic problem by going for possibility 1 and simply not thinking about it. :)

In both cases, the compiler won't complain; VanillaOption checks the type of the engine only indirectly, through the type of its arguments class, and that one will be correct since you inherit VanillaOptionFuture::arguments from VanillaOption::arguments.

Both possibilities will work, but the relationships between classes are not very well defined, which might make the code confusing to readers. As I said, though, QuantLib doesn't have a right way to do this, so the way you're proposing looks good to me.

• What about a private inheritance? Private inheritance implies VanillaOptionFuture uses VanillaOption. – SmallChess Jan 7 '16 at 0:56
• That would cause VanillaOptionFuture to inherit twice from Instrument (once privately through VanillaOption and once publicly because it is an Instrument). It's diamond inheritance, and Instrument has a lot of behavior. Making it work might be more trouble than it's worth. – Luigi Ballabio Jan 7 '16 at 9:33
• @LuigiBallabio I followed alternative number 2. Thanks for the help. – Giancarlo Giuffra Jan 9 '16 at 21:25