C++ Weekly - Ep 532 - What Does var{} Do?

Added: 2026-05-11

[00:00:00]Hello and welcome to C++  Weekly. I'm your host Jason Turner. This episode is going to be about a specific question that a viewer asked and this is your reminder that I do have an episode idea tracker that you should  check out and contribute to.

[00:00:15]This is also your reminder that I will be at ACCU on Sea giving a two-day  Best Practices workshop, CppCon, and NDC Techtown. Make sure you check those out. So the  viewer asked about braced initialization. Basically, what does it mean?

[00:00:34]What exactly am I initializing here? Today's episode is sponsored by JetBrains.

[00:00:41]"CLion is a cross-platform JetBrains IDE for C and C++. It is ready for your projects out of the box and has everything you need to stay productive, focused, and in control. Deep language understanding with intelligent code assistance, comprehensive build system support, unit testing frameworks, advanced debugging, and embedded development. Use the code CppWeeklyCLion to get 25% off when purchasing a new CLion subscription or renewing your existing one." Let's do a quick aside, and every compiler warns on this, but on line 15, I am not declaring an object of type d; this is the most vexing parse.

[00:01:26]I have forward declared a function that is called d and returns an object of type Data. That is not what we wanted to do. If I do this without anything here, this object has had its lifetime begin and its default constructor is called, but this thing called Data does not have a default constructor. So what am I doing? What are these values initialized to?

[00:02:03]Now this is partially dependent on which C++ standard you're using. As of C++ 26, we've got a rule change.

[00:02:14]This thing is uninitialized. So d.val is uninitialized and it is undefined behavior to read d.val in  C++23 and it is erroneous behavior in C++26.

[00:02:38]As of C++26, the compiler is not allowed to just throw away our program because we read an initialized value, it must  give us some kind of value.

[00:02:52]Now I want you to observe here that Clang is returning the value 2.

[00:02:58]Which standard am I currently using with Clang? I'm using C++23.

[00:03:03]I'm going to switch this to C++26, and it's still just returning the value 2. I'm going to enable optimization and  I get the value 104 returned from main. If I put this back to -O0, then I get the value 2  returned. But in either way, the compiler is really truly just treating this like undefined behavior. Clang still is not correctly supporting this rule. I mean, it kind of is. It's at least putting the ret here, and if you saw previous examples, it didn't do that, it  completely removed the entire body of main. Now let's look over here at GCC.

[00:03:45]GCC is properly telling me  I am accessing this value uninitialized. There's more to this story that you need to observe. Both of these compilers have address sanitizer and undefined behavior sanitizer enabled. Both of  them should be triggering when I read an uninitialized value and neither of them is regardless of the optimization level or the C++ standard that I have enabled. So here is another rant about undefined behavior from me, if that's what you think  you signed up for, but let's get back to this. So if I do these braces here, I am actually telling the compiler to default initialize these things.

[00:04:39]This one has been default initialized. The default initialization for integer is in fact going to be 0. This is required by the standard; this is true for all of the built-in types. So this thing is going to correctly return zero on every version of the standard and from every compiler, assuming no  compiler bugs, and we can see "Program returned: 0" here  and "Program returned: 0" here. The questions that you might have is if I access some value inside of more, yes, that is also default initialized. If I access some value inside of other, yes, that is also going to be default initialized, and if I take off this default initialization, we're going to see Clang put back some nonsense of some sort, I'm sure. Oh, 0 today. Thanks, Clang, and I'm getting the warning from GCC as I expect  it. Let's turn initialization back on and again, observe that neither compiler with any optimization level is triggering on the sanitizers and this is incredibly frustrating to me, but that is the current state of our compilers apparently.

[00:06:05]Okay, the next thing that you're going to want to ask is, "What happens if I provide, like, a value to this thing?"

[00:06:20]This is the question that I'm sure many of you are going to ask, and it is "What have I just done here? What is the value of other subscript 2?" Now notice I do get "warning: missing initialization for 'Data::more',"  etc. from these compilers but they're both returning 0 in this case. I have initialized all of those members; I pretty sure I have default initialized all those members, some of you might have something else that you would like to add as a comment here, perhaps there's some corner  of the standard that I've been missing. Let's go ahead though, and do something like ".val=" and this is perfectly valid, I can specify the initialization of a single value and let  the compiler work out the rest of it. I'm going to make a suggestion to you though, instead of questioning yourself as to what exactly do these rules mean, go ahead and make sure that these  things are always initialized because even with the address sanitizer and the undefined  behavior sanitizer enabled, I'm not getting anything out from this.

[00:07:48]Again, that is very frustrating. This however, is not frustrating. I could even do something like this, where I... this should compile.

[00:08:02]Yeah. I have initialized the first three members of.more with {1, 2, 3}. Everything  else in this object is default initialized. So let's check out.more of value 2, I should get 3 returned from main from both compilers. Yes, and if I do subscript 3, then I should get 0 returned from both compilers, and in fact, I do. Let's see if Valgrind is willing to do something more intelligent for us today, shall we? This is the example that may or may not have undefined behavior in certain situations, and we're not getting sanitizer results from it like we would prefer; so annoying. Let's go ahead and remove this initialization.

[00:08:49]Let's only initialize.more and let's call other of 10. Now if our hypothesis is correct, this should return 0 from every compiler, and maybe we will or will not get some sort of warning from Valgrind. I'm intentionally compiling with no optimizations. Here we go: "All heap blocks were freed -- no leaks are possible... 0 errors from 0 contexts, no suppressed errors." All right, let's go ahead and remove the initialization entirely, and we get uninitialized values were, in fact, read. Neat. It isn't really telling me where that happened. And let's do one other one, which was giving us a warning. Like that. We are not getting the uninitialized read.

[00:09:54]All right, there you go.  A little bit of a rambling episode. Hopefully it made some sense.

[00:09:58]Hopefully it cleared up some things. Hopefully it convinced you to continue to use your tooling so that you can get the best checks possible from your C++ code. Thank you for watching this episode of C++ Weekly. Be  sure to subscribe. I will see you at an upcoming conference workshop.