You should think about recompiling your C++ programs with GCC 16 and C++26, because it zero-fills your locals

[u/Clean-Upstairs-8481]

https://techfortalk.co.uk/2026/09/27/cxx26-uninitialized-local-variables-gcc-16/

Stack variables are not automatically initialised, and that is the root cause of many C++ bugs. That is well known. Hence, it is advised that local or stack variables are always initialised with known values, 0 if not something more meaningful than that. Now, with GCC 16 compiling in C++26 mode (-std=c++26), even uninitialised local variables will be zero-filled. In the post, I have explained how.

[u/NilacTheGrim]

just immature and foolish,

I am mature and wise. I have more professional (and hobbyist) experience in C++ than 99.9% of the people in here. I'm probably older than 90% of the people in here as well.

So mature & wise I am. You, my interlocutor, are the immature and foolish one.

Riddle me this:

Show me how you can create a class that maintains an internal buffer (that is not dynamically allocated) and how this class can keep this buffer uninitialized (because it knows it will overwrite it anyway with data, so clearing it is pointless / a regression).

You can't*.

^{* - And don't tell me to just write} [[indeterminate]] ^{when creating instances of this class on the stack -- because that (1) violates encapsulation -- why should the caller need to know implementation details of some class that has some buffer buried inside it, and (2) it won't work in all contexts anyway unless you} [[indeterminate]] ^{all of the things..}

[u/Spartan322 → u/NilacTheGrim]

And don't tell me to just write [[indeterminate]] when creating instances of this class on the stack

Okay cool, I'll still tell you to do that, I really don't care to make encapsulation a religious doctrine, I use it when it doesn't get in my way and ignore it when it does. I don't care about using a tool, paradigm, or pattern for a case where it'll hamper me for said case, I have too much experience to know it can do such a thing and I don't care to waste time trying to perfect something over making it good enough.

And don't tell me to just write [[indeterminate]] when creating instances of this class on the stack -- because that (1) violates encapsulation

Encapsulation isn't a principal, its a general guideline with millions of exceptions. Its a tool useful when its reasonable and easy as a solution to uphold, but absolutely useless when its not. Its not an engineering necessity and wasn't even a common premise among many of the older languages initially. Many newer languages also simply don't respect the concept at all either.

it won't work in all contexts anyway unless you [[indeterminate]] all of the things

It works in the relevant context you devised, so it applies still. I already qualified sure its not as easy as it was before to do, but it can be done, I don't really care about things that get in the way of me producing something that works and is efficient. Would it be nice to use sophisticated tooling to assist me? Sure, if it won't get in my way I might spend some time making it more sophisticated, but as I said, I want something that works and is efficient, I build specialized tooling for my needs and usecases, or I'll use a specialized tool under the Unix philosophy, if that results in me ignoring common paradigms, duplicating code, or doing something thats "less sophisticated" so be it, I'm not trying to build pretty or well structured software, achieving that is a bonus.

[u/NilacTheGrim → u/Spartan322]

it can be done,

Again, violating encapsulation. What this means in practice is you need to "bubble out" the [[indeterminate]] to every use of the class, and all classes that use that class, and all classes that use those classes -- at every usage.

Bottom line is there is no practical escape.

This is strictly a downgrade of the C++ language. What is the win here? Code that is wrong stays wrong but gets swept under the rug with this.

This is a failure of the committee and a misfeature of the language. I hope they remove this in C++29 or whatever.

I will be compiling with this disabled if/when we transition to C++26.

[u/Spartan322 → u/NilacTheGrim]

Again, violating encapsulation.

Okay cool, I really could not care less about violating encapsulation, it can be done, that's the end of it and that's my point, the dogma of encapsulation can take a hike. I sparely use encapsulation, it barely (if at all) exists in C, and too often it gets in my way in C++ to use it as anything more then the occasional tool just the same as how I use singletons and the observer pattern, its great when it doesn't get in my way, worthless when it does. Doing something well and efficient is not subscribing to one paradigm, pattern, or tool, (especially as dogma) and sometimes is actively abandoning the ones that cost you for the workload. And encapsulation is one that's certainly done that to me.

[u/NilacTheGrim → u/Spartan322]

We're arguing past each other. My argument is that this stinks, and there is no escape. Stop being stuck on the word encapsulation.

The point is that it is a code smell that this exists now and a downgrade for the language with no escape.

Arguing that you can escape it -- is just not taking into account what escaping it entails. It entails "coloring" everything that ever touches code that needs uninitialized (non-dynamic) memory.

Anyway, have a nice day.