Templates - Advice I suppose.

[chemicalNova]

Howdy all,

I'm wondering. Why would one use templates? I mean, I see a use for them.. but limited. Books and tutorials can all use the basic "Foo" template class example, but it still seems a little pointless to me.

I guess my question is.. where would you use one? Why? I'm having trouble understanding how I would apply them to my applications, should the need arise (or, if I could potentially replace a heap of code with a template for the same purpose).

Any advice would be great,

chem

[kedaman]

You are asking the wrong questions. If you are looking for particular examples in which a template could be useful, you are trying to clean your teeth with a hammer. To understand the real power behind templates you need to know what is wrong with C++ and all other object oriented programming languages. You need to know what the point is with object oriented programming, and why it does a very lousy job at it. You need to know what kind of crappy code is being produced by all the lousy compilers and you need to know what pointless sacrifices are being made in filling the leaking buckets over and over and going around the mountain because nobody will make the effort to dig the tunnel.
Templates exist only to do one thing, to allow abstraction and reuse of code in so far it does not undergo compilation, the polar opposite of what object oriented programming does. Their usefulness can only be envisioned in terms of potential applications of the same code in various cases. The procedure is basically the same as in polymorphism in object oriented programming, in that you are looking at typical functionalities and abstract them in order to allow a spectrum of furher implementations, thus avoiding code repetition aka reinvention of wheels. Unfortunately neither object oriented programming nor generic programming has been able to solve this problem in a satisfactory manner but has forced programmers to make compromises regarding the concept of reusability for one of the two reasons why you would not adhere to either paradigm. Templates, are effectively a failed attempt to solve the problem of a leaking bucket by using non leaking pipes, rather than patching the holes. As long as we are dealing with rigid code, all overhead we expect from polymorphism in object oriented programming can be eliminated, by evaluations done at compile time rather than at runtime. In this sense polymorphism is only one of the culprits, albeit one of the biggest, in producing bloatware. For some examples of innovative and succesful uses of templates, just take a look at the STL, or the spirit parser library that comes with boost. Also google for expression templates - there was something called vector expression templates about 7 years ago that would speed up vector math by altering the order in which calculations are done by not clogging up the registers by evaluating each part of the expression at a time, which inspired me to write the Bork expression templates that would allow a more generic use of expression templates. Now their use seems to have become quite widespread.

[chemicalNova]

Wow thanks. I think I will look the spirit parser, and google a bit more

chem

[CornedBee]

Trust keda to take the most extreme view

Templates find most of their applications in libraries or library-like code, not in concrete applications. That's why, as long as you're writing applications, you don't write them that often. (But you might find yourself using them a lot.)

The basic, and originally intended, use case for templates is when you have code that works on objects, but where you don't really care what these objects are as long as they have some properties. This is, in fact, the basis for all polymorphism, be it run-time subtype polymorphism (base and derived classes with virtual functions) or compile-time generics polymorphism of templates.
The tradeoffs are different, though. Run-time polymorphism pays the price in terms of speed, by requiring virtual calls, and code flexibility, by requiring subtype relations, or instead even more speed in duck-typed languages such as Python.
Compile-time polymorphism runs at full speed, but does so by generating separate code for each use case, and thus leading to larger executables, less cache coherency, and the inability to transparently plug in new types at runtime.

Consider the prototype template: vector<T>.
vector does not care about the type of its elements, as long as it is copyable. Thus, it is polymorphic. When choosing the type of polymorphism, there are several considerations.
One consideration, of course, is language capabilities. Java's Vector class is runtime polymorphic because Java didn't have anything else back then. On the other hand, C++ doesn't have a mono-rooted type hierarchy (no top-level Object everything else derives from), so subtype polymorphism is actually out of the question. But templates make sense for a few other reasons:
1) As many Java programmers have found out, you don't want to sacrifice speed on something as low-level as a vector. Really, you don't. (Large Vectors/ArrayLists of primitives in Java are dog slow, mostly due to boxing/unboxing.)
2) Collections tend to be uniform, not mixed. Run-time polymorphism always allows mixed collections. Compile-time only when you explicitly request it.

There are more reasons, but the end result is this: vector is better as a template.

Vector, however, is a typical library component. It's a basic building block for larger things.

Expression templates were discovered later. But they, too, are only found in libraries.

The reason is simple: templates must be instantiated. There must always be client code using the template for it to have a concrete existence. If there is client code, the template is a library-like component.

[chemicalNova]

Thanks CornedBee..that was more along the lines of what I was after

chem