I've been using C++ for a decade. Of all the warts, they all pale in comparison to the default initialization behavior. After seeing thousands of bugs, the worst have essentially been caused by cascading surprises from initialization UB from newbies. The easiest, simplest fix is simply to default initialize with a value. That's what everyone expects anyway. Use Python mentality here. Make UB initialization an EXPLICIT choice with a keyword. If you want garbage in your variable and you think that's okay for a tiny performance improvement, then you should have to say it with a keyword. Don't just leave it up to some tiny invisible visual detail no one looks at when they skim code (the missing parens). It really is that easy for the language designers. When thinking about backward compatibility... keep in mind that the old code was arguably already broken. There's not a good reason to keep letting it compile. Add a flag for --unsafe-initialization-i-cause-trouble if you really want to keep it.

C++, I still love you. We're still friends.

Oh how I wish the C++ committee and compiler authors would adopt this way of thinking... Sadly we're dealing with an ecosystem where you have to curate your compiler options and also use clang-tidy to avoid even the simplest mistakes :/

Like its insane to me how Wconversion is not the default behavior.

> If zero initialization were the default and you had to opt-in with [[uninitialized]] for each declaration it’d be a lot safer.

I support that, too. Just seems harder than getting a flag into Clang or GCC.

https://leanpub.com/cppinitbook

(I don't know whether it's good or not, I just find it fascinating that it exists)

Related: Initialization in C++ is Seriously Bonkers (166 points, 2019, 126 points) https://news.ycombinator.com/item?id=18832311

A wonderful exploration of an underexplored topic--I've pre-ordered the hard copy and have been following along with the e-book in the interim.

But I'm going to go out on a limb here and guess you don't do that. You actually do allow the C++ compiler to make assumptions that are not explicitly in your code, like reorder instructions, hoist invariants, eliminate redundant loads and stores, vectorize loops, inline functions, etc...

All of these things I listed are based on the compiler not doing strictly what you specified but rather reinterpreting the source code in service of speed... but when it comes to the compiler reinterpreting the source code in service of safety.... oh no... that's not allowed, those are training wheels that real programmers don't want...

Here's the deal... if you want uninitialized variables, then explicitly have a way to declare a variable to be uninitialized, like:

    int x = void;

A programmer wants the compiler to accept code that looks like a stupid mistake when he knows it's not.

But he also wants to have the compiler make sure he isn't making stupid mistakes by accident.

How can it do both? They're at odds.

Would it really be that unreasonable to have initialisation be opt-out instead of opt-in? You'd still have just as much control, but it would be harder to shoot yourself in the foot by mistake. Instead it would be slightly more easy to get programs that can be optimised.

I'm more annoyed that C++ has some way to default-zero-init but it's so confusing that you can accidentally do it wrong. There should be only one very clear way to do this, like you have to put "= 0" if you want an int member to init to 0. If you're still concerned about safety, enable warnings for uninitialized members.

So, do you?

    int i;

  #include 
  
  struct T1 { int mem; };
  
  struct T2
  {
      int mem;
      T2() {} // “mem” is not in the initializer list
  };
  
  int n; // static non-class, a two-phase initialization is done:
  // 1) zero-initialization initializes n to zero
  // 2) default-initialization does nothing, leaving n being zero
  
  int main()
  {
      [[maybe_unused]]
      int n;            // non-class, the value is indeterminate
      std::string s;    // class, calls default constructor, the value is ""
      std::string a[2]; // array, default-initializes the elements, the value is {"", ""}
      //  int& r;           // Error: a reference
      //  const int n;      // Error: a const non-class
      //  const T1 t1;      // Error: const class with implicit default constructor
      [[maybe_unused]]
      T1 t1;            // class, calls implicit default constructor
      const T2 t2;      // const class, calls the user-provided default constructor
      // t2.mem is default-initialized
  }

C++ is fun!

[0]https://en.cppreference.com/w/cpp/language/default_initializ...

> "There's a great language somewhere deep inside of C++"

or something to that effect.

And that's not just said out of unfamiliarity. I'm a professional C++ developer, and I often find I'm more familiar with C++'s more arcane semantics than many of my professional C++ developer co-workers.

idk, seems like years of academic effort and research wasted if we do the way C++ do it

  struct foo {
    int a = 0;
  };

It is.

COBOL Language Frontend Merged For GCC 15 Compiler Written by Michael Larabel in GNU on 11 March 2025 at 06:22 AM EDT. 33 Comments

All well and good if it is something you do not have to modify/maintain on a regular basis. But, if you do, then the ROI on replacing it might be high, depending on how much pain it is to keep maintaining it.

We have an old web app written in asp.net web forms. It mostly works. But we have to maintain it and add functionality to it. And that is where the pain is. We've been doing it for a few years but the amount of pain it is to work on it is quite high. So we are slowly replacing it. One page at a time.

It’s shameful that there’s no good successor to C++ outside of C# and Java (and those really aren’t successors). Carbon was the closest we came and Google seems to have preemptively dropped it.

Usually what happens is the language requires you to initialize the variable before it's read for the first time, but this doesn't have to be at the point of declaration. Like in Java you can declare a variable, do other stuff, and then initialize it later... so long as you initialize it before reading from it.

Note that in C++, reading from a variable before writing to it is undefined behavior, so it's not particularly clear what benefit you're getting from this.

“The systems programmer has seen the terrors of the world and understood the intrinsic horror of existence.”

https://www.usenix.org/system/files/1311_05-08_mickens.pdf

you don't know how much C++ code is being written for 100-200MHz CPUs everyday

https://github.com/search?q=esp8266+language%3AC%2B%2B&type=...

I have a codebase that is right now C++23 and soon I hope C++26 targeting from Teensy 3.2 (72 MHz) to ESP32 (240 MHz). Let me tell you, I'm fighting for microseconds every time I work with this.

the people who care about clock ticks should be the ones inconvenienced, not ordinary joes who are maintaining a FOSS package that is ultimately stuck by a 0-day. It still takes a swiss-cheese lineup to get there, for sure. but one of the holes in the cheese is C++'s default behavior, trying to optimize like it's 1994.

I mean that's pretty much the main reason for using c++ isn't it? Video games, real-time media processing, CPU ai inference, network middleware, embedded, desktop apps where you don't want startup time to take more than a few milliseconds...

In another era we would have just called this optimal. https://x.com/ID_AA_Carmack/status/1922100771392520710