5 ms·

> 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

> 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.

vacuity 1y ago
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.
- tialaramex 1y ago
  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.
gosub100 1y ago
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.
- jcelerier 1y ago
  > 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=repositories&s=updated&o=desc 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.
  - vjvjvjvjghv 1y ago
    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.
    - jcelerier 1y ago
      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.
  - gosub100 1y ago
    "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.
    - jcelerier 1y ago
      > 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...
wffurr 1y ago
>> Systems are not sane. “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 https://www.usenix.org/system/files/1311_05-08_mickens.pdf
creata 1y ago
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.
- pjmlp 1y ago
  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.
  - tialaramex 1y ago
    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.
    - pjmlp 1y ago
      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.
int_19h 1y ago
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; ... } If you do actually want an uninitialized variable, you say so: var x: i32 = undefined; This rule also takes care of structs by applying recursively.

vacuity 1y ago

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.

tialaramex 1y ago
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.

gosub100 1y ago

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.

jcelerier 1y ago
> 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=repositories&s=updated&o=desc 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.
- vjvjvjvjghv 1y ago
  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.
  - jcelerier 1y ago
    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.
- gosub100 1y ago
  "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.
  - jcelerier 1y ago
    > 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...

wffurr 1y ago

>> Systems are not sane. “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 https://www.usenix.org/system/files/1311_05-08_mickens.pdf

creata 1y ago

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.

pjmlp 1y ago
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.
- tialaramex 1y ago
  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.
  - pjmlp 1y ago
    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.

int_19h 1y ago

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; ... } If you do actually want an uninitialized variable, you say so: var x: i32 = undefined; This rule also takes care of structs by applying recursively.