> Explicitly initialize your variables, and if you ever fall in to the trap of thinking C++ is a sane language, remember this
It's a systems language. Systems are not sane. They are dominated by nuance. In any case the language gives you a choice in what you pay for. It's nice to be able to allocate something like a copy or network buffer without having to pay for initialization that I don't need.
C and Rust both tend to be more sane than C++, though, so you can't just pin it on C++ being a systems programming language.
Agree with Rust, with C, only when people think they know C, but never opened a page of ISO C, or spent afternoons reading compiler manuals about language extensions and implementation specific behaviors.
I spent about two decades getting paid to write C before I learned Rust so I feel confident describing myself as an expert. It's true that C's abstract machine is a much stranger thing than many of its proponents believe - and that it's not very like any computer built this century so that the "portable assembler" claims are plain delusional, but I will say it's definitely less crazy than C++, more sane if you will.
This has become a bit less true in C17 and C23, but a lot of that is driven by the urge from WG21 (the C++ committee) to have WG14 (C language) do their work for them, hopefully some WG14 members will push back against that.
Agreed, now if WG14 actually cared about sensible improvements regarding strings and arrays.
As for latest ISO C revisions, not sure if it is doing any WG21 work other that the whole #embed drama, rather it looks to me pushing for a C++ without Classes, with a much worse design, e.g. _Generic.
I think in this case it's not amiss to mention Rust. Rust gives a compile error if it's not certain a variable is initialized. Option is the standard dynamic representation of this, and works nicely in the context of all Rust code. MaybeUninint is the `unsafe` variant that is offered for performance-critical situations.
To clarify for anybody else following along (I assume you knew), the type MaybeUninit isn't unsafe (Rust doesn't have unsafe types), only its method named assume_init and related APIs are unsafe.
That's because only this feature introduces the potential for safety problem, which is amusing because it doesn't actually do anything per se, it will often emit zero CPU instructions.
It's unsafe because before we called this function we had a MaybeUninit<T> and, well as it said, maybe it isn't initialized, so nothing will assume it is. But once we assume_init, we've got a T, all the code working with the T, including safe Rust code, is entitled to ignore any scenarios that could arise if it were not, in fact, initialized properly. Despite not in some sense "doing" anything, the unsafe call was critical.
>> Systems are not sane.
“The systems programmer has seen the terrors of the world and understood the intrinsic horror of existence.”
Zig is also a systems language, yet it doesn't have this problem because every local variable must have an explicit initializer. So this simply won't compile:
pub fn main() void {
var x: i32;
...
}
var x: i32 = undefined;
That may have made sense in the days of < 100 MHz CPUs but today I wish they would amend the standard to reduce UB by default and only add risky optimizations with specific flags, after the programmer has analyzed them for each file.
> That may have made sense in the days of < 100 MHz CPUs
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.
I bet even there you have only a few spots where it really makes a difference. It’s good to have the option but I think the default behavior should be safer.
I don't know, way too often often my perf traces are evenly distributed across a few hundred functions (at best), without any clear outlier.
"how much code" =/= how many developers.
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.
> the people who care about clock ticks
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...
No, it's not a dichotomy of having uninitialized data and fast startup or wait several milliseconds for a jvm or interpreter to load a gigabyte of heap allocated crap.
it's not about startup time. it's about computational bandwidth and latency once running.
They are doing what you want. It is a long difficult process to figure out what is UB - most of it is cases where there is nothing written down and so it UB by default - it wasn't defined. Once UB is found and documented then they get to figure out what to be done about it. In some cases nothing as realistically nobody does that, in the case in question they have defined what happens, but the article is 8 years old.
CPU speed is not memory bandwidth. Latency and contention always exist. Long lived processes are not always the norm.
In another era we would have just called this optimal. https://x.com/ID_AA_Carmack/status/1922100771392520710