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

Posted by andrea-110 on
URL: http://quantlib.414.s1.nabble.com/PATCH-Payoffs-fully-implemented-in-a-foreign-language-via-SWIG-tp13242.html

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

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev