Posted by
Luigi Ballabio-2 on
Jul 16, 2003; 4:51am
URL: http://quantlib.414.s1.nabble.com/Policy-Based-Design-Templates-Quantlib-tp2601p2603.html
At 01:19 PM 7/14/03 -0400, Nehal Patel wrote:
>Thanks for the post(s). For whatever reason I have yet to get a good grasp
>on the benefits of compile time polymorphism/templates -- that is: how does
>one identify which situations are good for applying templates (again
>ignoring the standard examples of containers or generic algorithms or smart
>pointers)?
As a very, very rough rule of thumb, I'd use run-time polymorphism for
interfaces and compile-time polymorphism for implementations. Something like:
class Engine {
public:
virtual void calculate() const = 0;
};
template <typename T, class Policy>
class SomeEngine : public Engine {
public:
void calculate() const;
};
but I'm sure there are very obvious counter-examples to the above. I mostly
go by gut-feeling myself...
>At this point, the major benefits seem to be: 1) Ability to
>avoid certain runtime, type check errors
True, and it can go way further than you would expect: for an application
we won't be using in QuantLib, see
http://oonumerics.org/tmpw01/brown.pdfwhere templates are used for (brace yourself) compile-time dimensional
analysis of physical formulas...
>2)Ability to produce optimized code in certain situations (for instance
>you can get away with inline expansion in some cases for which normal
>runtime polymorphism would have lead to an indirection + real function call).
Also, compilers often cannot do their fancy optimizations around virtual
calls. And adding up inlining and optimization you can save quite a few
cycles, as you just found out for the BermudanSwaption example...
>I guess at the end of the day, templates provide a way of providing
>optimized code without sacrificing too much of the design?
Yes. Also, 3) with run-time polymorphism you can have virtual methods, but
not "virtual types", while templates allow you to use traits---see e.g.
http://www.moderncppdesign.com/publications/traits.html> The tradeoff is that it is not easy to document the "required"
> interface for a class template parameter (but of course the compiler will
> quickly tell you if you try to use a class with an incomplete interface
> for a given template -- but of course the error message will be
> book-lengthed and utterly unintelligible :)
I agree---the required interface should be documented.
>Anyway I guess I am looking for a killer example of some templated policy
>design that would have been difficult to achieve using an inner class
>member variable with a fixed interface.
Hmm, I don't really know about killer apps... for a survey of template
programming and its use for efficient calculations, you can have a look at
http://osl.iu.edu/~tveldhui/papers/techniques/techniques.psFor examples of what is possible to do with templates, see Todd
Veldhuizen's papers at
http://osl.iu.edu/~tveldhui/papers/and Andrei Alexandrescu's at
http://www.moderncppdesign.com/publications/Later,
Luigi