Modern C++ Features – Uniform Initialization and initializer_list

With this post I’ll start a series on new C++ features, where new means C++11 and up. I usually won’t go into too much technical details of the features, because especially the more commonly known C++11 features have been covered elsewhere. Instead, I will try to shed some light on how these features can be used to make code more simple and readable. Today I’ll begin with uniform initialization syntax and initializer_lists.

Uniform Initialization

In C++03, initialization of variables has been different for different kinds of variables, and sometimes it was not even possible. With C++11 we got so-called *uniform initialization*, which attempts to make the whole topic a bit easier for developers.

Uniform initialization is pretty simple: you can initialize practically everything with arguments in curly braces. The compiler then will do just the right thing.

Consider this C++03 code:

There are several problems and one outright error connected to initialization in this code, that uniform initialization in C++11 can fix. Let’s look at all the initializations one after another.

Initializing POD Class Members

In C’s constructor only the member variable d gets initialized, which is not very clean. We should strive to initialize every member variable in the initializer list, because if we don’t plain old data types remain uninitialized and contain garbage values, not even zeroes.

The problem is, that in C++03, aggregates can not be initialized in the initialization list but instead need to get their values assigned later. With uniform initialization they can:


As you can see, the double member which is no aggregate can be initialized with curly braces as well.

Calling Constructors and the Most Vexing Parse

In C++03 there is a problem called the “most vexing parse”, and it originates from the fact that parenthesis are used as well for function declarations, function calls and initializations.

The simplest example is the “explicit call of a default constructor” which is not possible in C++03. If a call with one argument looks like C c(22);, then with zero arguments it should look like C c();. However, the compiler parses this as a declaration of a function c, returning a C and taking no arguments. We therefore had to rely on an implicit call of the default constructor, writing C c;

Line 21 is not very different – we *think* we are constructing a D, named d, with two constructor arguments being a default-constructed C and a default-constructed POD. But the compiler reads this as a declaration of a function called d, returning a D, taking as first argument a function returning a C with no parameters and as second a function returning a POD with no arguments.

With uniform initialization, the curly braces are not ambiguous, and we can use any initialization that would be victim to the most vexing parse otherwise:

Of course we can call any constructor with curly braces.

Initializing Plain Old Data and Aggregates

Given what I have written about uniform initialization by now, the initialization of plain old data and aggregates won’t come as a surprise, so I’ll just dump the remaining lines of main with uniform initialization for completeness:

As you can see, there is no more need to “adjust” values after the initialization of an aggregate, since the can get all the needed values through uniform initialization.

Construction of Function Parameters

You can even construct function parameters on the fly, without stating their type, as long as the parameter types stay unambiguous. For example, there is only one constructor of D, so the following line is not ambiguous:

It simply says “default construct the first and second argument” – and the compiler can figure which type those arguments should have.


In standardese, the curly braces with the list of elements are called braced-init-list, and the list of elements itself is called initializer-list. In some cases it would come handy if we just could construct an object of class type with such a list, e.g. if we could initialize a container with a list of its elements, just like an array:

And indeed a way to achieve this has been included into the C++11 standard which makes the above line valid C++.

C++11 introduces a new type std::initializer_list<T>. Objects of that class are container proxies with forward iterators and a size to a temporary array.

They are primarily meant for such list initializations but can also be used for function calls, e.g. f({1, 2, 5}); calls a function f that has an initializer_list<int> parameter.

std::initializer_list and Uniform Initialization

Mostly, the two features I presented play very well together, for example if you want to initialize a map you can use an initializer-list of braced-init-lists of the key value pairs:

Here, the type of the pairs is clear and the compiler will deduce, that {"Alex", 522} in fact means std::pair<std::string const, int>{"Alex", 522}.

But sometimes, initializer_list constructors can compete against the other constructors. The most prominent example is std::vector<int>‘s constructor for a size and a single value argument that the vector should be filled with:

The intention is clear from the naming, the programmer would have expected to get a vector that has twelve elements, each having the value 5. However, the compiler sees this as a call to vector‘s initializer_list constructor, producing a vector with two elements, with the values 12 and 5.

To get the desired behavior in cases like this, the old school syntax with parenthesis has to be employed: std::vector<int> aDozenOfFoves(12, 5);


Uniform initialization abstracts away details that are in most cases unnecessary to know, like if an object is an aggregate or of class type. The uniformity enhances readability.

Use uniform intialization where possible.

std::initializer_list should be treated carefully. If you write a class that can really benefit from it, use it, but be aware of the interference with normal constructors. In addition, avoid using std::initializer_lists as standalone objects. There is not much use to it, and there are some problems with auto type deduction.

Use std::initializer_list sparsely and with care.

The last guideline for today is about the omission of function argument types. You will have noticed that the construction of the D object becomes pretty obscure if we use only the braced-init-lists, especially if they are empty. A forest of curly braces does not enhance readability.

On the other hand, when constructing the map of scores, the purpose of the initializers were pretty clear, there was no need to explicitly state the type of pairs that were constructed.

Omit the types of brace-initialized function arguments only if they are very clear from the context. Prefer readability and explicitness over brevity.

Facebooktwittergoogle_plusredditlinkedinFacebooktwittergoogle_plusredditlinkedinby feather


  1. Rahul

    > Uniform initialization abstracts away details that are in most cases unnecessary to know, like if an object is an aggregate or of class type.

    Not always. Consider the following:

    1. Arne Mertz

      Yes, perhaps I should rephrase that part – uniform initialization levels some of the differences between aggregates and classes but not all.

      I agree that this is not like we would like to have it, but I think it is perfectly clear that an aggregate std::array can not possibly be initialized the same way as a C-array, because it encapsulates the C-array inside an aggregate, therefore the extra curly braces are needed. If you’d put an std::array inside another aggregate you’d need yet another layer of braces:

      Also, if you had a class that contains a vector of elements and should be initialized with such a vector, you would have to use the same double layer of braces as for a std::array:

      So the difference here is not really between aggregates and classes but between the levels of nesting (conceptual or real) in std::array (2 levels), C-arrays and std::vector (1 level each)


Leave a Reply

Your email address will not be published. Required fields are marked *