The article is good about explaining when and how code is generated, but I think that the fibonacci example does more harm then good because this is one of those fancy 'template hacks' which I wouldn't use for real-world code. A few really useful real-world use cases for templates are (IMHO):
- they can make interfaces more simple by using template methods/functions (have a single method which is specialized by the compiler, instead of polluting the API with 20 slightly different methods which only differ by the argument type)
- they can enable a coding style which 'looks and feels' almost dynamic without loosing the strict type checks and optimization opportunities that a static type system provides
- they can help to keep related data close together in memory and minimize dynamic memory allocation (e.g. an array of structs instead of an array of pointers)
- the compiler has more optimization opportunities because it has more type information (vs. a more dynamic system where types are only known at runtime)
The tradeoff is of course that the compiler generates more (specialized) code, it breaks the simple rule that the amount of generated code grows linearly with the number of lines of code. On the other hand the compiler has a lot more type info to optimize the generated code. Still the programmer has to know what's happening under the hood so he can weigh the advantages against the disadvantages.
Part of what is great about C++11/C++14 is constexpr's. It moves ll this "compute ahead of time" logic in to a simpler and more familiar structure.
There is actually a tremendous amount of value of precomputing a lot of work that is currently computed at runtime (the amount of wasted CPU in your typical C++ program, particularly at start time, is kind of crazy). It's just that the real hot spots in real world programs programs tend to revolve around runtime dynamic logic.
I'm agree with you and aware about the fact that the Fibonacci metafunction is not a good example of real metaprogramming (Computing Fibonacci series using tmp has no much sense). I only picked that example because its recursive structure is pretty well known (Is one of the most common first examples used to teach recursion), so fits well to show people how a complex template is instanced, which is the idea of that part of the post. Compare that with using an instance of std::vector, for example. Is a much more realistic example, but people usually doesn't know about the inside of a vector and how it's structured internally. The main objective of these posts is to explain tmp in away that everybody understands it well. When we all are well covered about the basics, we will can get into more complex and realistic cases in depth. That's exactly why more complex examples included in the post, like build_string, are not explained in depth. Are more a proof of concept.
- they can make interfaces more simple by using template methods/functions (have a single method which is specialized by the compiler, instead of polluting the API with 20 slightly different methods which only differ by the argument type)
- they can enable a coding style which 'looks and feels' almost dynamic without loosing the strict type checks and optimization opportunities that a static type system provides
- they can help to keep related data close together in memory and minimize dynamic memory allocation (e.g. an array of structs instead of an array of pointers)
- the compiler has more optimization opportunities because it has more type information (vs. a more dynamic system where types are only known at runtime)
The tradeoff is of course that the compiler generates more (specialized) code, it breaks the simple rule that the amount of generated code grows linearly with the number of lines of code. On the other hand the compiler has a lot more type info to optimize the generated code. Still the programmer has to know what's happening under the hood so he can weigh the advantages against the disadvantages.
[edit: formatting]