[Quantlib-dev] [PATCH] Payoffs fully implemented in a foreign language via SWIG

[Andrea <mar...@go...>]

I would like to post 2 patches (one for QuantLib, the other for QuantLib-SWIG) to allow users to
implement a payoff entirely in a foreign language (e.g. Java).
These patches apply on top of the other patch I have just sent.

By enabling directors the user can implement the "value" function in Java like it was a standard
subclass of a C++ class.

The goal here is not speed :-) but ease of use, by writing a payoff in a language like Java or C#.

There is also a simple example of an option that pays the running average on every fixing date.

Everything works fine with the exception of the following issue. But I thought to post the code
since I could not find a better solution that what I have currently implemented.



Basically I want to expose to Java a hierarchy like that

class PathPayoff
{
	virtual ....... = 0; // this is the payoff interface
};

class PathOption
{
	virtual vector<Date> fixingDates() = 0;

	virtual boost::shared_ptr<PathPayoff> payoff() = 0;		<<<<<<<<< PROBLEM
};

No problem for PathPayoff, but huge issues on how to implement PathOption::payoff() in Java.
Basically the problem is how to create in Java a shared_ptr containing an object inherited from
PathPayoff (which is implemented in Java as well).
I know how to create a raw pointer (which is already managed by SWIG/Java), but I don't think this
pointer can be safely stored into a shared_ptr (i.e. there would be double management).

So I've changed and exposed only one class

class ExternalOption
{
	virtual ....... = 0; // this is the payoff interface
	virtual vector<Date> fixingDates() = 0;

	boost::shared_ptr<PathOption> convert(); // helper to convert an ExternalOption into a PathOption
};

this class contains all functions required to describe a contract.
Then there is a function that converts the ExternalOption into a PathOption using a custom wrapper.
The problem now is that the wrapper contains a reference (C++ reference) to the ExternalOption, so
that there could be problems if someone tried to use the Wrapped PathOption after the ExternalOption
has gone out of scope of garbage collected.

I wish I had a shared_ptr<ExternalOption> but I only have a raw pointer or a reference.

It is a problem similar to the original, but I found it is easier to manage. It is all down to the
use of shared_ptr in SWIG.

If anyone has a comment or better solution I would be delighted to hear about it.

Andrea