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 |
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 |
Free forum by Nabble | Edit this page |