3 ms·

It's catastrophic actually. Like disastrously catastrophic. It started with C++20 mostly, and has only kept getting worse from then. See zero initializing varia

by rfgplk 8d ago

It's catastrophic actually. Like disastrously catastrophic. It started with C++20 mostly, and has only kept getting worse from then. See zero initializing variables by default (WHY?) compare/meta including half the STL and HARDCODING those symbols, std::initializer_list being in the std namespace (if you don't include <initializer_list> you literally can't use it, and there is no such thing as a __initializer_list or some internal symbol), the entire coroutine library where you MUST provide coroutine_handle, noop_coroutine, suspends et al (coroutines aren't that bad because they're not necessarily spaghetti). <meta> is the single WORST OFFENDER, where they hardcode std::vector (literally std::vector in the std namespace) std::ranges std::allocator.

aw1621107 8d ago
> See zero initializing variables by default Strictly speaking the standard only requires some pattern that is not tied to program state. Zero works for that, but so do other static patterns like 0xABAB... or the like. > (WHY?) The motivation section of the corresponding paper [0] might be interesting. tl;dr: it lets wrong code be wrong without suffering from (all) the consequences of full-blown UB. [0]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2795r5.html#motivation https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p27...
- fc417fc802 8d ago
  In other words, it's a sane default that you can opt out of on a case by case basis which is the way it should have been all along.
- WalterBright 7d ago
  D initializes floating point variables to NaN by default. And chars to 0xFF. Yes it's controversial!
- dahart 7d ago
  I’d guess the concern is performance, not what initializer value is used. And performance is a valid concern that is discussed in the proposal, and a reason there’s an escape hatch. Still, it might cause some confusion.
- TuxSH 7d ago
  AFAIK zero-init is unfortunately the default compiler use (but you can change that)
mitxela 7d ago
I can't find anything saying variables are zero initialized by default in C++20. But the reason to do so is obvious: many bugs are caused by the lack of this, and as long as you can opt out with "= void" or something, it's not violating C++ core principles.
- dahart 7d ago
  They were saying the problematic philosophy started in C++ 20, not the variable initialization rule. Yes the reason is obvious, but it’s neither simple nor black and white. One huge problem is that this can cause serious performance regressions, and you have to change your code to opt out, e.g. add “[[indeterminate]]”. There are many, many cases in high performance computing where the intended & desired behavior is don’t touch my variables until I fill them. This is changing C++ core principles, there’s a new designation for the state of a variable: erroneous. It’s also subtle and weird, because you can still have well-defined behavior even with erroneous state. It does seem like this might be an experiment though, I don’t think this is the end of the story. (It seems they’re already talking some redesign of this idea.)
  - ack_complete 7d ago
    What I'm most annoyed at with the variable initialization change is that: - It's potentially a performance change in every single function, especially ones that have sizable fixed-size buffers - If you have regressions you have to spray [[indeterminate]] everywhere, because there is no coarser way of suppressing it. - While the language says unrecognized attributes are ignored, compilers frequently warn on unrecognized attributes. Clang, for instance, currently warns on [[indeterminate]]. - There is no defined macro name for backwards compatibility. Which means that libraries are going have to all declare their own macros for [[indeterminate]] and pepper their code with it.
  - mitxela 7d ago
    Uninitialized variables were already UB to read, because some architectures have trap representations, even for integers. Every register on Itanium has one.

by rfgplk 8d ago

aw1621107 8d ago

> See zero initializing variables by default Strictly speaking the standard only requires some pattern that is not tied to program state. Zero works for that, but so do other static patterns like 0xABAB... or the like. > (WHY?) The motivation section of the corresponding paper [0] might be interesting. tl;dr: it lets wrong code be wrong without suffering from (all) the consequences of full-blown UB. [0]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2795r5.html#motivation https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p27...

fc417fc802 8d ago
In other words, it's a sane default that you can opt out of on a case by case basis which is the way it should have been all along.
WalterBright 7d ago
D initializes floating point variables to NaN by default. And chars to 0xFF. Yes it's controversial!
dahart 7d ago
I’d guess the concern is performance, not what initializer value is used. And performance is a valid concern that is discussed in the proposal, and a reason there’s an escape hatch. Still, it might cause some confusion.
TuxSH 7d ago
AFAIK zero-init is unfortunately the default compiler use (but you can change that)

mitxela 7d ago

I can't find anything saying variables are zero initialized by default in C++20. But the reason to do so is obvious: many bugs are caused by the lack of this, and as long as you can opt out with "= void" or something, it's not violating C++ core principles.

dahart 7d ago
They were saying the problematic philosophy started in C++ 20, not the variable initialization rule. Yes the reason is obvious, but it’s neither simple nor black and white. One huge problem is that this can cause serious performance regressions, and you have to change your code to opt out, e.g. add “[[indeterminate]]”. There are many, many cases in high performance computing where the intended & desired behavior is don’t touch my variables until I fill them. This is changing C++ core principles, there’s a new designation for the state of a variable: erroneous. It’s also subtle and weird, because you can still have well-defined behavior even with erroneous state. It does seem like this might be an experiment though, I don’t think this is the end of the story. (It seems they’re already talking some redesign of this idea.)
- ack_complete 7d ago
  What I'm most annoyed at with the variable initialization change is that: - It's potentially a performance change in every single function, especially ones that have sizable fixed-size buffers - If you have regressions you have to spray [[indeterminate]] everywhere, because there is no coarser way of suppressing it. - While the language says unrecognized attributes are ignored, compilers frequently warn on unrecognized attributes. Clang, for instance, currently warns on [[indeterminate]]. - There is no defined macro name for backwards compatibility. Which means that libraries are going have to all declare their own macros for [[indeterminate]] and pepper their code with it.
- mitxela 7d ago
  Uninitialized variables were already UB to read, because some architectures have trap representations, even for integers. Every register on Itanium has one.