templating functions when to do it ?

[eskimo456]

Hi
I am currently primarily programing graphics applications and am still fairly new to this. I know the relevance and can see the advantages of making items a template especially with things such as collision detection.

I was wandering is there any advantage/disadvantage to doing everything as a template?
Obviously if you want a function to only work on a specific task then it makes sense to only allow items of that class to be able to access it. However for the majority of things I have wrote so far could be wrote as a template and then reused as many times as I want.

Is there any overheads with writing everything as a template? IS there any time it should be avoided? Or is it good practice to write everything as a template unless otherwise needed?

Many thanks
curious how things work in the real world and if it is bad practice to template most of the code

[NathanOliver]

IMHO any class or function that you write that you use with different data types should be a template so you don't have to keep copy and pasting code and possibly creating an error in doing so. That said if you are writing a simple function for a program and you feel you will only use it there then there really isn't any advantage to template it. I would equate it to non library functions and library functions. with non library functions they get used in one program and that's mostly it. with library function they get used in many programs and should be flexible enough to not be changed.

[mike_2000_17]

>>is there any advantage/disadvantage to doing everything as a template?
Advantages:
- You get truly generic, expendable implementations.
- You suffer no run-time overhead (and often a speed-up).
- Policy, Traits, and Concepts are much more flexible than base classes or interfaces in OOP.
- Inversion of Control (IoC) can be implemented with no overhead.
- Template specializations and special overloads allow you to write case-specific implementations, thus, improving performance.
- Etc. there are many more that I am forgetting.

Disadvantages:
- The implementation (or definition) of all algorithms and functions have to be distributed with the library (you are forced to provide an open-architecture library, you cannot have pre-compiled libraries).
- Increased compilation times.
- Code bloat, both in terms of having to often mix declarations and definitions, and in terms of creating larger executable with much "duplicated" code (although you are not duplicating that code yourself, the compiler does).
- It is more difficult to achieve run-time polymorphism (requires OOP wrappers).

>>Is there any overheads with writing everything as a template?
No. Except for increased compilation times, but the run-time code will be as efficient or more efficient than any non-templated procedural or OOP equivalent.

>>IS there any time it should be avoided?
If you can suffer the disadvantages mentioned above, then NO.

>>Or is it good practice to write everything as a template unless otherwise needed?
It is never good practice to have those kinds of "one-size-fits-all" rules. You cannot say that because templated code is "always" better, you will template everything you do. That's bad practice. Understand the advantages of templated code and use it when appropriate or beneficial. The argument is similar to that of operator overloading in C++. Don't overload operators in a way that changes the semantics of the operation. Well, don't make function templates if the function's semantics don't generalize very well. If your functions generalize well, but only to a certain category of types, then make sure that it is clear what Concept those types should satisfy (there are different ways to do this: template specializations / special overloads, a consistent template-argument naming convention, static assertions based on concept checking (see Boost.Concept-Check), and Sfinae techniques using concept-checks and type-traits).

>>how things work in the real world and if it is bad practice to template most of the code
Generic programming is fairly young. But it has been gaining significant attention in the past 5-10 years, and support from the compiler vendors is also better and better (much better than just a few years ago). Amongst C++ programmers, I think that today the wave of enthusiasm for OOP has passed and people are embracing more and more the power of multi-paradigm programming (i.e. using the appropriate style when appropriate, not camping into a narrow-minded, single-paradigm view of programming). And generic programming is a great why to enhance all paradigms. It alleviates flexibility issues with procedural programming (C-style programming), it achieves (static) polymorphism without the run-time overhead found in OOP, it reduces repetitive coding, it allows for DSELs (Domain-Specific Embedded Languages) which extend the programming language, it provides much stronger compile-time error checking (reduces debugging time), it is type-safe all-the-way, etc. etc. The only reason why there aren't more libraries out there that use generic programming is due to the inherent inertia of library development (people use old and robust libraries and can't change it, people are not willing to do complete rewrites, etc.), you still see libraries out-there where the authors boast on how revolutionary their library is because it is the first OOP implementation for a particular problem (maybe it was revolutionary 20 years ago, but it ain't today, especially if it's a misplaced use of OOP).

[eskimo456]

Excellent many thanks for the fast replies and the clarification. I will start to template things that will be beneficial (such as collision detection) and won't worry about unnecessary things a brilliant explanation and very helpful
Thank you again