4 ms·

I don't really care if it isn't portable. I only have to work with Clang, personally. > If zero initialization were the default and you had to opt-in with [[u

by loeg 1y ago

I don't really care if it isn't portable. I only have to work with Clang, personally. > 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.

ryandrake 1y ago
Portability is always for the other guy’s sake, not your own. That’s why so many people don’t care about it.
- loeg 1y ago
  Again, I'm not opposed to the idea, it just seems more challenging logistically.
motorest 1y ago
> I don't really care if it isn't portable. You don't care because your job is not to ensure that a new release of C++ doesn't break production code. You gaze at your navel and pretend that's the universe everyone is bound to. But there are others using C++, and using it in production software. Some of them care, and your subjective opinions don't have an impact in everyone else's requirements. > I only have to work with Clang, personally. Read Clang's manual and check what compiler flags you need to flip to get that behavior. It's already there.
- loeg 1y ago
  Lmao. You've misread both of my upthread comments and have somehow arrived at the conclusion that this justifies personal attacks. There's just no discussion to be had here.
TuxSH 1y ago
Gcc already has [[gnu::uninitialized]] (clang doesn't, AFAIK), as well as -ftrivial-auto-var-init=pattern which exactly matches the new C++26 semantics, if I'm not mistaken
- loeg 1y ago
  > -ftrivial-auto-var-init=pattern I believe this only helps for trivial automatic variables; not non-trivial automatic variables (structs/classes) that contain uninitialized trivial members.
  - TuxSH 1y ago
    Ah, you're right, thanks for correcting me! This also doesn't apply to heap-allocated variables, though I think p2795r2 should cover all these cases. I wonder if (for stack variables) this is due to an implementation detail in the compiler. After all, non-trivial classes have 'actual' constructors that run and that is supposed to initialize their respective class instances...

by loeg 1y ago

ryandrake 1y ago

Portability is always for the other guy’s sake, not your own. That’s why so many people don’t care about it.

loeg 1y ago
Again, I'm not opposed to the idea, it just seems more challenging logistically.

motorest 1y ago

> I don't really care if it isn't portable. You don't care because your job is not to ensure that a new release of C++ doesn't break production code. You gaze at your navel and pretend that's the universe everyone is bound to. But there are others using C++, and using it in production software. Some of them care, and your subjective opinions don't have an impact in everyone else's requirements. > I only have to work with Clang, personally. Read Clang's manual and check what compiler flags you need to flip to get that behavior. It's already there.

loeg 1y ago
Lmao. You've misread both of my upthread comments and have somehow arrived at the conclusion that this justifies personal attacks. There's just no discussion to be had here.

TuxSH 1y ago

Gcc already has [[gnu::uninitialized]] (clang doesn't, AFAIK), as well as -ftrivial-auto-var-init=pattern which exactly matches the new C++26 semantics, if I'm not mistaken

loeg 1y ago
> -ftrivial-auto-var-init=pattern I believe this only helps for trivial automatic variables; not non-trivial automatic variables (structs/classes) that contain uninitialized trivial members.
- TuxSH 1y ago
  Ah, you're right, thanks for correcting me! This also doesn't apply to heap-allocated variables, though I think p2795r2 should cover all these cases. I wonder if (for stack variables) this is due to an implementation detail in the compiler. After all, non-trivial classes have 'actual' constructors that run and that is supposed to initialize their respective class instances...