Home » Blog » 2012 » December » Is C++11 uniform initialization a replacement for the old style syntax? -- Programmers.StackExchange

Is C++11 uniform initialization a replacement for the old style syntax? -- Programmers.StackExchange

By Joel Lamotte | Dec 20, 2012 09:09 AM | Tags: basics

Here is a question from Programmer's StackExchange (tags [c++] and [c++11]) which most C++ developers, whatever their level, will ask as soon as they are introduced to the new Uniform Initialization syntax:

Is it recommended now to use uniform initialization in all cases? What should the general approach be for this new feature as far as coding style goes and general usage? What are some reasons to not use it?

The accepted answer clearly provides very good reasons to use this new syntax as much as possible (if your compiler supports it already): minimizing redundant typenames and avoiding the Most Vexing Parse. It also points some reasons to not use this syntax, in particular in case you're trying to call a standard container constructor.

There is one other reason not to:

std::vector<int> v{100};

What does this do? It could create a vector<int> with one hundred default-constructed items. Or it could create a vector<int> with one item whose value is 100. ... In actuality, it does the latter.

Read the full QA.

Read Stroustrup's FAQ about Uniform Initialization syntax.

Add a Comment

Comments are closed.

Comments (6)

0 0

Zenju said on Dec 20, 2012 10:51 AM:

I haven't seen this discussed anywhere so I want to mention the elephant in the room for non-US C++ programmers:

Did anyone ever test this new syntax on a German keyboard? It's painfully inconvenient to use curly braces, much more than the old parantheses.

However the new lambda syntax take the cake! Entering [](){} is pure torture... I'm not joking. As much as I love the semantics of both these features, they couldn't be possibly harder to type on a German keyboard as they are. It's almost impossible to enter any of those without at least one typo!

I mitigated the pain by creating an autohotkey script which types the lambda syntax for me whenever I press "win + y", I get a pair of curly braces with "win + x". However, this cannot be supposed to be a mainstream solution... ? Am I missing something?
0 0

Joel Lamotte said on Dec 20, 2012 12:44 PM:

Zenju, until this year I've been using French keyboard so I can relate, even if I got used easily because I have big hands. I decided to switch for a Uk keyboard recently for different reasons, one being that most programming language syntax are designed by people extremely familiar with English and US keyboard. I believe there is no way to take into consideration keyboard layout other than the US one when designing a language, as it would be a formidably terrible constraint.

So I guess you should try to get used to it...or maybe do like me, have both local and US/UK keyboard available at all time and get used to switching.
0 0

Cedric said on Dec 21, 2012 08:46 AM:

Bonjour Joel,

I don't find the new uniform initialization syntax that tricky, and the last example looked obvious to me: if I'd wanted to call the constructor I would have used parenthesis "naturally", without thinking too much about it.

Although I feel conformatble with this new syntax I am almost not using it because in most "real life" situation the content of conainers is not known compile time; it is either entered by a user or loaded from a persistent storage. So except in my unit tests, I consider this new feature of few added value. I would have prefered that energy being spent on other language features.

A small poll here: what is your opinion about this feature? killer feature? useless? nice and fun?
0 0

Joel Lamotte said on Dec 22, 2012 10:10 AM:

Cedric, I agree that once you understand the subtelties of the new syntax, most cases become obvious. Still, the cases presented in the answer are exception easily forgotten and silently compiling. Also, think that, unfortunately, not all explanation of this new syntax is complete enough to explain the details necessary to spot the difference between both syntaxes, other than unifying the initializations.
On the filling containers on construction part, I agree that it's not the most common case, but it's still happening for example when I want to set a const std::map<> as a compile-time-defined table that should not be changed through the run of the program. When you need this, then there is a major performance problem without the initializer-list constructor: you have no other way to setup your container than by running a function that will fill it step by step. Even with using reserve() on some container, it's still something that is problematic in cases the compiler could have hardcoded the values or built everything in one read-only bloc of memory. That's where this new initialization syntax shine for containers: it solve a performance problem, that is not common every day but when it happen you need something like this.
1 0

Joel Lamotte said on Dec 22, 2012 10:15 AM:

There is another more common use of the container initialization syntax: composition of data. It happens often in my domain that a container is composed depending on input data but the way the container is filled is clearer and more efficient with this new syntax. For example, return { a, b, c, k }; returning a vector of values in a specific order, is clearer and more efficient than doing std::vector<Thing> v; v.push_back(a); v.push_back(b); ... return v; There is both a clarity, non-verbosity and efficiency (allocation can be in one big bloc at once without having to reserve after construction) that is provided by the new syntax.
0 0

Cedric said on Dec 26, 2012 04:24 AM:

OK, thank you Joel, your last example is more appealing to me, I did'nt consider it that way.