C++11 saw a bunch of changes to template handling that overall are fairly minor. The first two will I cover allow what seem fairly obvious things that I am sure most C++ programmers attempted when they were learning the language. The third is not really a language change in itself, but more of a method to help the compiler and linker do less work.

Right-angle Brackets
When specifying a template within a template, there is no longer a need to put a space between the “>“s. For example, a poor man’s matrix can now be specified as:

std::vector<std::vector<double>>

Not a big feature by any means, but a great improvement!

Template Aliases
There are limitations with typedef and templates. Specifically, typedef can only be used to define fully qualified types, so does not work in cases where you want to partially specialize a template. The standard example (as in, straight from the Standard) is if you want to provide your own allocator for a std::vector. Now you can define a type for that using:

template<class T>
  using Vec = std::vector<T, Alloc<T>>;
Vec<int> v;    // same as std::vector<int, Alloc<int>> v;


Note that ordinary type aliases can be declared using the using syntax instead of typedef, and in my opinion is a far nicer syntax.

Extern Templates
To understand this feature, you first need to have some idea about how C++ compilers deal with templates. Lets see if I can explain this correctly… Consider this code snippet:

Foo<int> f;
f.bar();

When the compiler reaches the first line, it does a implicit initialization of the constructor (and destructor) of Foo<int> (if it has not been done previously in this translation block). That is, it creates the code for the int version of Foo. Generating the code on usage makes sense with templates as we do not know what types will be used when we declare the class (hence the use of templates…). The second line accesses the bar() method of Foo<int> and so that function gets implicitly initialized.

A disadvantage of implicit initialization is that we would have to use every method to let the compiler catch issues when using a class with a particular type. Also, the initialize a bit here and there approach might be slower. To work around this we can do an explicit initialization of the class:

template class Foo<int>;

The disadvantage of this is that if you class has a method that is not usable for a particular type (e.g. due to a class method requiring an operator that is not implemented for the type), then an explicit initialization will try to initialize that method and fail. With implicit initialization, the methods are initialized as called and so the unusable method is never encountered by the compiler. This is all in C++03.

OK… more details about the compiler. What happens when we have two translation units that are compiled separately then linked together that both use the Foo<int>? At compile time, the compiler has no idea that both these files use the that class, so initializes it for both files as needed. Not only is this a waste of compiler time, but then the linker spots these two identical initializations and strips one out (ideally…), so it wastes linker time too. C++11 provides a way to deal with this. In one source file, Foo<int> gets explicitly initialized. Then in all remaining source files that link with this, template initialization can be suppressed using:

extern template class Foo<int>;

One potential use for this is creating a shared library. If you know the finite set of types your template class/function is going to be used for, you can provide a header with just the declarations and the required extern lines. In the library source, you provide the definitions and explicitly initialize them. That way, any users of your library will just have to include the header and they are done. The compiler will automatically not implicitly initialize anything.

A fairly common thing to do with an array or container is to loop over its values. Consider the following loop for loop over a std::vector<int> v:

for(std::vector<int>::const_interator i = v.begin(); i != v.end(); ++i)

Based on what is already covered in this series, we can simplify this statement to:

for(auto i = v.begin(); i != v.end(); ++i)

That is already a big improvement, but there is the tedium of always specifying the begin and end values. This is where the new range-based for loop syntax comes in. The entire expression can be reduced to:

for(auto i : v)

Note that i in this syntax is not the iterator, but the value the iterator points to so there is no need to dereference it in the loop body. All standard loop control such as break and continue can be used as in a traditional loop. If you want to modify the variable (or avoid passing around large data types by value) and the underlying iterator supports it, you should make the loop variable a reference:

for(auto& i : v)

This syntax can be used for arrays and any container from the STL. You can also use it on your own containers provided a few conditions are met. Firstly it must have either both begin() and end() member functions, or have free standing begin() and end() functions that take it as a parameter. These functions need to return an iterator, which by definition is required to implement operator++(), operator!=() and operator*().

Welcome to part 2 of my ramblings about C++11. Note that all of these posts are in the C++11 category, so it is easy to go an read previous entries. This post is going to focus on a new syntax for declaring the return type of functions.

Lets go back to the example of calculating a dot product of two vectors given in the first post of this series:

template<class T, class U>
void dot_product(const vector<T> vt, const vector<U> vu)

Once it is calculated, we probably want to actually return the value! However, we do not know the type of the output. Using decltype seems the way to go. For example:

template<class T, class U>
decltype(vt[0] * vu[0]) dot_product(const vector<T> vt, const vector<U> vu);

However, there is an issue here… And it is not the fact that vt[0] might not exist if you provide a zero length vector, as that does not matter (I guess because the return type of the [] operator is known). Nor is it that the result might overflow the type of an individual multiplication – stop being picky about fake code! The issue is that we do not know what vt and vu are at that stage of the function declaration. You could use:

decltype(*(T*)(0)**(U*)(0))

but the less said about that the better… This is where a new (optional) function declaration syntax comes into play:

template<class T, class U>
auto dot_product(const vector<T> vt, const vector<U> vu) -> decltype(vt[0] * vu[0]);

Although useful for templates, this syntax is really about scope. For example, consider:

class Foo
{
public:
  enum Bar { FOO, BAR, BAZ };
  Bar getBar();
private:
  Bar bar;
};

When defining the function getBar(), the following is wrong:

Bar Foo::getBar() { /* ... */ }

as Bar is out of scope – at that stage we do not know we are in a method for the Foo class. That can be easily fixed in this case by using Foo::Bar as the return type, but that can get messy in more complex cases. Better to use:

auto Foo::getBar() -> Bar { /* ... */ }

Then by the time Bar is reached, we know we are in the scope of the Foo class.

My C++ skills are getting a bit rusty as I have not done much programming in that language lately. So I thought what better way to refresh my skills and learn new stuff than to go through the C++11 changes and write something about them. I will not cover all additions and changes to the standard, but instead focus on those I am likely to use, (which means they must be implemented in GCC). And even those I do focus on, will likely miss some subtleties that I find unimportant (or more likely am unaware of…). For those wanting actual detail, a late working paper that is a near final draft of the C++11 standard can be downloaded here.

This first post is going to focus on type deduction and its uses.

auto
In C++98, you have to declare the type of every variable being used. C++11 introduces the auto keyword, which lets the compiler deduce the type of a variable given its initializer. So you could write:

auto x = 5;

and you would get that x is declared to be an int. Like everything in programming, there is times when you should use a feature and times when you should not… This is an example of a time where you should not. The use of auto should be reserved for situations where you really do not know the type of the result or that the type is unwieldy to write. For example:

template<class T, class U>
void dot_product(const vector<T> vt, const vector<U> vu)
{
  //...
  auto tmp = vt[i] * vu[i]
  //...
}

A bit of a contrived example, but it should be clear that the type of the result depends on the template parameters U and V so is unknown. I will get to the return type in the next post…

A more useful example where the type of the variable is known but unwieldy is:

std::vector<std::pair<std::string, int>> v;
//...
for(auto i = v.begin(), i != v.end(), ++i) {
//...

Here the type of i is known (std::vector<std::pair<std::string,int>>::const_iterator), but writing that would quickly become tedious and error prone. I guess most situations like this were previously handled with a typedef statement.

There are other uses of auto that will be covered in later posts when the relevant features are introduced.

decltype
The decltype operator takes an expression and returns it type. A trivial example:

int x = 5;
decltype(x) y = x;

This declares the variable y to have the same type as x. Of course you could use auto here (or preferably neither in this case…), but the use of decltype comes into its own when you actually need a type – for example, a return type, which will be covered in the second post in this series.