You probably don't want zero initialization if you can help it.
Ideally, what you want is what Rust and many modern languages do: programs which don't explain what they wanted don't compile, so, when you forget to initialize that won't compile. A Rust programmer can write "Don't initialize this 1024 byte buffer" and get the same (absence of) code but it's a hell of a mouthful - so they won't do it by mistake.
The next best option, which is what C++ 26 will ship, is what they called "Erroneous Behaviour". Under EB it's defined as an error not to initialize something you use but it is also defined what happens so you can't have awful UB problems, typically it's something like the vendor specifies which bit pattern is written to an "unintialized" object and that's the pattern you will observe.
Why not zero? Unfortunately zero is too often a "magic" value in C and C++. It's the Unix root user, it's often an invalid or reserved state for things. So while zero may be faster in some cases, it's usually a bad choice and should be avoided.
> Ideally, what you want is what Rust and many modern languages do: programs which don't explain what they wanted don't compile, so, when you forget to initialize that won't compile.
I think you're confusing things. You're arguing about static code analysis being able to identify uninitialized var reads. All C++ compilers already provide support for flags such as -Wuninitiaized.
Uninitialized variables reads can only sometimes be detected statically. -Wuninitialized is still good, but it will miss a lot of cases when the read is in a different translation unit. Whole program analysis could get more cases, but with large programs (multi-million lines of code) it is unlikely we can analyze everything (everything being more than just variables) before the universe ends - see the halting problem.
> Uninitialized variables reads can only sometimes be detected statically. -Wuninitialized is still good, but it will miss a lot of cases when the read is in a different translation unit.
From my experience, you're exaggerating the number of false negatives, which is more a factor of how you write your code than what static code analyzers do.
Also, your comment reads like an attempt at moving the goal post. We start this discussion being very adamant in accusing C++ of being impossible to detect uninitialized var reads. Once that assertion is thoroughly proven to be false and resulting from clueless ignorance, now we try to reframe it as being... Imperfect in some hypothetical scenarios? So what's supposed to be the actual complain?
The main problem with C++ is that some people somehow are personally invested in criticizing it from a position of complete ignorance. The problem is not technical, it's social.
I agree false negatives are rare - I was intending to temper expectations because perfection is impossible.
> You're arguing about static code analysis being able to identify uninitialized var reads.
(Safe) Rust does guarantee to identify uninitialised variable reads, but I believe the point is that you can get the optimisation of not forcing early initialisation in Rust, you just have to be explicit that that's what you want (you use the MaybeUninit type); you're forced to be clear that that's what you meant, not just by forgetting parens.
You can even write e.g. this:
let mut jim: Goat;
// Potentially much later ...
if some_reason {
jim = make_a_new_goat();
} else {
jim = get_existing_goat();
}
use(jim); // In some way we use that goat now
But, if we screw up and make it unclear whether jim is initialized, probably because in some cases it wouldn't be - that doesn't compile.
This is the usual "avoid early initialization" C++ programmers are often thinking of and it doesn't need MaybeUninit, since it's definitely fine if you're correct, it's just that the C++ compiler is happy (before C++ 26) with just having Undefined Behaviour if you make any mistakes and the Rust compiler will reject that.
[Idiomatically this isn't good Rust, Rust is an expression language so we can just write all that conditional if-else block in the initializer itself and that's nicer, but if you're new to this the above works fine.]
> (Safe) Rust does guarantee to identify uninitialised variable reads (...)
That's great. You can get that check on C++ projects by flipping a compiler flag.
Aren't we discussing C++?
What flag do you have in mind? (To the best of my knowledge, no such flag exists -- unless you're talking about one of the heavily penalized sanitizer modes.)
> To the best of my knowledge, no such flag exists
Your knowledge doesn't seem to even reach the point of having googled the topic. If you googled it once, you'd not be commenting it doesn't exist. Hell, you don't even seem to have read the thread, let alone the discussion.
Again with the personal attacks.
I'll note that you have failed to name this "obvious" flag that I'm missing.