Re: [Quantlib-dev] STL compliant containers for XLOPER

[Eric E. <eri...@na...>]

Hi Slava,

Wow, that is one impressive design.  You have pushed the XLOPER/STL/Boost
combination to its limit.

Every XLL library tries to solve the problem of separating the guts of an
XLOPER from its interface, your "duality" idea is the most elegant approach I
have seen yet.  I have considered the idea of inheriting from XLOPER and could
not get it to work but I think you have found a way.

I like the fact that you use different classes depending on whether XLOPER
memory is to be managed by Excel or the XLL.  Many libraries including
ObjectHandler and XLW use a single class with a switch and I find your
approach safer and more intuitive.

Many thanks for considering the idea of contributing this to ObjectHandler. 
The contribution would be welcome.  I understand that you would need to do
some negotiating on your side, please keep me posted.  Would you be able to
provide a statement authorizing the release of this code under the QuantLib
license?  Depending on you contract and the laws in your country it may be
that your thoughts are the property of your employer ;) in which case the
statement would have to come from them.

I'm in the process of packaging up the 0.9.6 release of ObjectHandler and
we're too late to add more to that, but we could get your classes onto the svn
trunk for inclusion in the next release.  I would put them in new folder
ObjectHandler/ohxl/xllcontainers in a sub-namespace.  As you note, your new
classes can be used independently of ObjectHandler and I would definitely want
to retain that orthogonality.

It would be good to get some example applications for XLL Containers, maybe
showing the usage of the classes with and without ObjectHandler?

As you observe, for ObjectHandler 0.9.6, boost::any is replaced everywhere by
property_t, which wraps boost::variant, because the latter is supported
natively by boost::serialization.  I'm not sure how this change impacts your
classes, which also use boost::any but in a different context.

Your design document could go into a new section of the ObjectHandler
documentation.  If you would like also to use doxygen compatible comments in
the code then those would be included in the reference manual.

Longer term I would consider the idea of using these classes for QuantLibXL,
but that would be more complicated.  The design of OH/QLA is platform
independent and all of the Excel bindings have C++ equivalents.  For example,
consider the conversion from a variant type to a QuantLib::Quote:

The abstract implementation of this conversion is
    convertQuote()
    in QuantLibAddin\qlo\conversions\conversion_tmpl.hpp
The C++ instantiation is
    convert2<boost::shared_ptr<QuantLib::Quote>, property_t>
    in QuantLibAddin\qlo\conversions\conversions.cpp
The Excel instantiation is
    convert2<boost::shared_ptr<QuantLib::Quote>, ConvertOper>
    in QuantLibXL\qlxl\conversions\opertovector.cpp

This approach allows us to have the conversion logic in one place where it is
reused by all platforms, for example if you serialize the Excel environment
into a stream that can be loaded by a QuantLib C++ application on Linux.  How
would that work if the ObjectHandler XLL and QuantLibXL were to use the XLL
Container classes in place of the existing Excel bindings?

Regards,
Eric

-------------------------
Eric Ehlers
nazcatech sprl | Brussels | http://www.nazcatech.be
Distributed computing for pricing analytics - Use Microsoft Excel as a client
to the Grid

On Mon, August 11, 2008 19:33, Slava Mazur wrote:
> Greetings,
>
>
>
> For more than a year I've been using several stl-compliant wrappers
> around XLOPER structure, which I've developed as an extension to
> ObjectHandler libraries and which I found pretty helpful and efficient.
>
> Although my solution is completely independent of ObjectHandler, I think
> it might make sense embedding my classes to it, so I'm considering
> contribution. Moreover, the latest developments in ObjectHandler and
> introduction of property_t class in particular makes me think that I
> ought to introduce my solution rather sooner than later.
>
>
>
> Please find the attached an incomplete draft version of documentation of
> implemented classes in html format which gives an idea what is all about
> and let me know if this makes any sense so that I could discuss such a
> contribution with other parties involved. If not, then well, I'll
> continue to use these classes as my own extension to ObjectHandler.
>
>
>
> Thanks,
>
>
>
> Slava Mazur
>
>
>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/_______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>