can any one please elaborate why template is being used i dont understand in most of the google page they say that we can reuse the code but even in inheritance we do that .why templates?????
Jump to Post
why templates? So that you don't have to write different functions that all do the same thing but with different data types. That's how its done in C language. For example if I need a function that returns the sum of two numbers but it need to handle int, float, …
All 2 Replies
why templates? So that you don't have to write different functions that all do the same thing but with different data types. That's how its done in C language. For example if I need a function that returns the sum of two numbers but it need to handle int, float, and double, one way to do it would be to write three different functions, one for each data type. The more efficient way to do it is to write just one template that returns the sum of two numbers of any data type.
The main tool for being able to reuse the same piece of code in different contexts is the ability to treat an object as an abstract entity (with some predefined set of functionality), which is what polymorphism means. This really boils down to being flexible about the types of the object. It is true that inheritance from abstract interfaces is one way to achieve this, but there are some problems with this mechanism. There is always a trade-off between type-flexibility and run-time overhead (and amount of code needed).
If you want an object to be polymorphic, you have to deal with it in OOP terms, with an abstract interface with virtual functions, and by creating the object dynamically (referring to it via base-class pointers). This incurs overhead in the form of indirect memory allocations (causing problems of locality of reference), in the form of dynamic dispatching (e.g., calling virtual functions, which causes difficulties for pre-fetching, which is a very important factor for performance), and in the form of limited static analysis (that's when the compiler analyses the code and figures out ways to simplify it, or optimize it). Also, the more types of objects you have to deal with, the more interfaces you have to construct, increasing the amount of code. Furthermore, even with multiply inheritance and virtual inheritance, it is often difficult to get flexible class hierarchies (one class implementing many interfaces, or collaborating with other classes). And sometimes, when mixing two libraries each with their own class hierarchies one has to go through many hoops to blend the two things well (often requiring a choice of which hierarchy to adopt as the primary one (or your own) and somehow mixing in the other hierarchy).
Then, you still have the problem that very simple types (like primitive types), have to either be fixed completely, or be made into a class hierarchy, which usually entails prohibitive overhead due to the simplicity of the underlying operations. For example, with Ancient Dragon's example of a simple function to sum two numbers, you could implement a base-class called ArithmeticValue, and then derive it as Integer, Double and Float classes, each with a complete set of arithmetic operations implemented as virtual functions, and then write your "sum" function in terms of the base class ArithmeticValue. But in such a case, the overhead will be very large in proportion to the simplicity of the actual operations being done. That's why you won't see this anywhere (except in Java/C#, which actually does this). The point is, you have to decide to draw the line somewhere to preserve reasonable performance, and that line is where the flexibility ends.
Templates, on the other hand, don't suffer this overhead at all, in fact, quite to the contrary. You don't have to draw a line where flexibility is no longer deemed possible. In fact, the place where you draw a line is where you need run-time flexibility (being able to change the types of the objects being used at run-time). Where you want run-time flexibility, you use OOP style code based on inheritance for doing polymorphism. So, what you see very often in C++ code is that the core algorithmic code is implemented through function and class templates to allow for flexibility down to the primitive-type level and all the way up to complex OOP classes. Then, one usually constructs the high-level building blocks in a OOP class hierarchy whose derived objects actually just use these core algorithmic codes under-the-hood. This is also why most algorithmic libraries, like the STL or many of the Boost libraries, are almost entirely written using templates (by what is called "generic programming" and "template meta-programming").
Furthermore, templates allow for things you couldn't imagine doing in an OOP structure. Some benefits of templates include the very sparse inter-dependencies between types, where in OOP, you often spend a lot of time trying to fit the pieces of the puzzle in the correct order, in generic programming, that is rarely a problem (but it sometimes is). Benefits also include the ability to "compute types", or what is called template meta-programming, which allows all sorts of fancy things to be done at compile-time (instead of having to do them at run-time), one example of that is "expression templates" with which you can essentially build a compiler that runs as the code is being compiled (allowing things like writing a symbolic math expression solver and optimizer, which does its work during compilation only, resulting in very fast code at run-time). Techniques relying on templates can also be used to force the compilers to enforce certain custom rules (such as matching units in a math expression) such that most errors can be caught during compilation (as opposed to having to chase down bugs at run-time). Other template-related techniques can also be used to implement double-dispatching schemes effectively (which has been proven to be impossible in OOP). And finally, with templates it is much easier to blend different libraries together because polymorphism based on templates is inherently non-intrusive and wrappers can be easily made without any overhead.
The main problems with templates are that (1) they only offer compile-time flexibility, (2) they can lead to very long and cryptic compiler errors, and (3) the language rules (and compiler compliance) related to templates are far from being trivial, making templates a rather difficult world to get into, but as you get comfortable with them, the benefits far out-weight the drawbacks, in my opinion.
Overall, OOP is useful when you want run-time flexibility, but otherwise, templates are the preferred solution, and you'd be surprised how often compile-time flexibility is really all you need.
Be a part of the DaniWeb community
We're a friendly, industry-focused community of 1.20 million developers, IT pros, digital marketers, and technology enthusiasts learning and sharing knowledge.