C++ Templates: The Complete Guide

Author: David Vandevoorde, Nicolai M. Josuttis
4.5
All Stack Overflow 33
This Year Stack Overflow 4
This Month Stack Overflow 4

Comments

by Firas Assad   2017-08-20

C++ Templates: The Complete Guide is your best bet. You could also learn about the Standard Library which heavily uses templates.

by anonymous   2017-08-20

With templates we simply don't have clean output facilities and there are no compilers i know of that allow you to directly view template instantiations. The closest i found regarding metaprogram debugging was a paper on Templight.

For now the best utilities seem to be:

by anonymous   2017-08-20

Short summary

This is just the way the current C++11 rules are: this->bar.baz<int>() introduces a dependent name not in the current instantiation context that requires disambiguation with the template keyword, even though it is very hard to come up with an actual example of a competing parse that change the semantics of the expression this->bar.baz<int>().

Parsing ambiguity from angle brackets

First: why in general is there a need for template?

When a C++ compiler encounters an expression f<g>(0), it can interpret this either as "call the function template f for template argument g and function argument 0 and evaluate the result" or it can mean "make the comparison (f<g)>(0) for names f and g and constant 0." Without further information it cannot make this decision. This is an unfortunate consequence of the choice of angle brackets for template arguments.

In many (most) cases, the compiler does have enough context to decide whether a template expression or a comparison is being parsed. However, when a so-called dependent name (essentially a name that is explicitly or implicitly dependent on a template parameter of the current scope) is encountered, another language subtlety comes into play.

Two-phase name lookup

Because a name dependent on a template could change its meaning (e.g. through specializations) when a template is being instantiated for a concrete type, name lookup of dependent names is done in two phases (quote from C++ Templates the Complete Guide):

During the first phase, nondependent names are looked up while the template is being parsed using both the ordinary lookup rules and, if applicable, the rules for argument-dependent lookup (ADL). Unqualified dependent names (which are dependent because they look like the name of a function in a function call with dependent arguments) are also looked up that way, but the result of the lookup is not considered complete until an additional lookup is performed when the template is instantiated.

During the second phase, which occurs when templates are instantiated at a point called the point of instantiation (POI), dependent qualified names are looked up (with the template parameters replaced with the template arguments for that specific instantiation), and an additional ADL is performed for the unqualified dependent names.

Why this-> makes your code different

Using this-> inside a class template introduces a dependent name and triggers two-phase name lookup. In that case, the rule cited by @40two comes into play. The point is that the ADL at the 2nd phase can bring in new names from explicit specializations that redefine the meaning of your bar and baz and it could conceivably change the meaning of this->bar.baz<int>(0) to a comparison rather than a function template call.

Granted, for non-type template arguments such as this->bar.another_baz<0>() this would be more likely than for a type template parameter. In this related Q&A a similar discussion arose whether one could find a syntactic valid form that changes the meaning of this->f<int>() vs this->template f<int>(0), without a clear conclusion.

Note that C++11 already relaxes the rule for template disambiguation compared to C++98. Under the current rules this->f<int>() for a template<class> f() inside Foo would not require template because it is in the so-called current instantiation. See this answer from the canonical Q&A for this topic for more details

by anonymous   2017-08-20

What are C++ Expression Templates in simple terms?

Expression templates are a category of C++ template meta programming which delays evaluation of subexpressions until the full expression is known, so that optimizations (especially the elimination of temporaries) can be applied.

Are there books around that discuss numerical methods/computations using C++ Expression Templates?

I believe ET's were invented by Todd Veldhuizen who published a paper on it 15 years ago. (It seems that many older links to it are dead by now, but currently here is a version of it.) Some material about it is in David Vandevoorde's and Nicolai Josuttis' C++ Templates: The Complete Guide.

In what way, C++ Expression Templates are better than using pure C?

They allow you to write your code in an expressive high level way without losing performance. For example,

void f(const my_array<double> a1, const my_array<double> a2) 
{ 
  my_array<double> a3 = 1.2 * a1 + a1 * a2; 
  // ..
}

can be optimized all the way down to

for( my_array<double>::size_type idx=0; idx<a1.size(); ++idx ) 
  a3[idx] = 1.2*a1[idx] + a1[idx]*a2[idx]; 

which is faster, but harder to understand.

by anonymous   2017-08-20

This question is also addressed specifically in the definitive book on C++ Templates ("C++ Templates: The Definitive Guide", by Vandvoorde and Josuttis), Section 7.1, p.87 (at least in my edition):

7.1 "Class Template" or "Template Class"?

[snip]

There is some confusion about how a class that is a template is called:

The term class template states that the class is a template. That is, it is a parameterized description of a family of classes.

The term template class on the other hand has been used

  • as a synonym for class template.

  • to refer to classes generated from templates.

  • to refer to classes with a name that is a template-id.

The difference between the second and third meaning is somewhat subtle and unimportant for the remainder of the text.

Because of this imprecision, we avoid the term template class in this book.

Similarly, we use function template and member function template, but avoid template function and template member function.

(Anyone, I mean anyone, working with C++ templates should have a copy of this book, by the way.)

by anonymous   2017-08-20

Templates are a very powerful mechanism which can simplify many things. However to use them properly requires much time and experience - in order to decide when their usage is appropriate.

For me the most important advantages are:

  • reducing the repetition of code (generic containers, algorithms)
  • reducing the repetition of code advanced (MPL and Fusion)
  • static polymorphism (=performance) and other compile time calculations
  • policy based design (flexibility, reusability, easier changes, etc)
  • increasing safety at no cost (i.e. dimension analysis via Boost Units, static assertions, concept checks)
  • functional programming (Phoenix), lazy evaluation, expression templates (we can create Domain-specific embedded languages in C++, we have great Proto library, we have Blitz++)
  • other less spectacular tools and tricks used in everyday life:
    • STL and the algorithms (what's the difference between for and for_each)
    • bind, lambda (or Phoenix) ( write clearer code, simplify things)
    • Boost Function (makes writing callbacks easier)
    • tuples (how to genericly hash a tuple? Use Fusion for example...)
    • TBB (parallel_for and other STL like algorithms and containers)
  • Can you imagine C++ without templates? Yes I can, in the early times you couldn't use them because of compiler limitations.
  • Would you write in C++ without templates? No, as I would lose many of the advantages mentioned above.

Downsides:

  • Compilation time (for example throw in Sprit, Phoenix, MPL and some Fusion and you can go for a coffee)
  • People who can use and understand templates are not that common (and these people are useful)
  • People who think that they can use and understand templates are quite common (and these people are dangerous, as they can make a hell out of your code. However most of them after some education/mentoring will join the group mentioned in the previous point)
  • template export support (lack of)
  • error messages could be less cryptic (after some learning you can find what you need, but still...)

I highly recommend the following books: