Re: [Quantlib-dev] DerivedQuote design

[Luigi B. <lui...@gm...>]

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