DerivedQuote design

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

DerivedQuote design

DU VIGNAUD DE VILLEFORT FRANCOIS GASAPRD PHI

Hi all,

 

A quick question about the DerivedQuote class design: The operation performed by this class is a template parameter yet the actual operation is actually known only at run time. What about using a more informative template so that the operation can be known at compilation time and inlined ? (we would loose the possibility to change the operation at run time but who cares ?).

To be as explicit as possible, the DerivedQuote value method would be written like this:

 

    template <class UnaryFunction>

    inline Real DerivedQuote<UnaryFunction>::value() const {

        QL_ENSURE(isValid(), "invalid DerivedQuote");

        return UnaryFunction::eval(element_->value());

    }

 

François

 


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev
Reply | Threaded
Open this post in threaded view
|

Re: DerivedQuote design

Luigi Ballabio

Hi François,

On Wed, 2007-09-05 at 16:12 +0200, DU VIGNAUD DE VILLEFORT FRANCOIS
GASAPRD PHI wrote:
> A quick question about the DerivedQuote class design: The operation
> performed by this class is a template parameter yet the actual
> operation is actually known only at run time.

No, it is usually known at compile-time.  The current implementation of
value() calls operator() on the passed UnaryFunction instance, whose
type is usually known (we're taking a copy of it, so there's no
polymorphic behavior) and whose code can be inlined.  The cases in which
this is not possible is just when UnaryFunction is a function pointer
(in the C style.)


>  What about using a more informative template so that the operation
> can be known at compilation time and inlined ? (we would loose the
> possibility to change the operation at run time but who cares ?).
>
> To be as explicit as possible, the DerivedQuote value method would be
> written like this:
>
>     template <class UnaryFunction>
>
>     inline Real DerivedQuote<UnaryFunction>::value() const {
>
>         QL_ENSURE(isValid(), "invalid DerivedQuote");
>
>         return UnaryFunction::eval(element_->value());
>
>     }

You mean, eval() should be a static method of the UnaryFunction class?
Unfortunately, this would mean that:
a) you can't use existing functions (which have no methods at all) or
function objects (which define operator() instead) unless you adapt
them;
b) you can't use function objects that hold non-static data
members---not even by adapting them.

Luigi


--

For every problem there is one solution which is simple, neat, and
wrong.
-- H. L. Mencken



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev