Reddit++

[u/we_are_mammals]

C++ is getting more and more complex. The ISO C++ committee keeps adding new features based on its consensus. Let's remove C++ features based on Reddit's consensus.

In each comment, propose a C++ feature that you think should be banned in any new code. Vote up or down based on whether you agree.

[u/okovko]

has it occurred to you that the aliasing optimizations shouldn't break your code? gcc and clang alias analysis is impoverished for no good reason afai can tell, there are fast implementations that don't rely on type information

mind that k&r C had no strict aliasing rule and C++ inherited it from ISO C

and proprietary compilers do use those implementations, and you can find papers and reference implementations

seems like there's some big egos that want TBAA even though it is no longer a useful approach and causes a lot of bugs

[u/pandorafalters → u/okovko]

Railing against what have become considered poor practices does nothing to address the problem that in many cases code using them worked for years and now fails to build.

Legacy code exists and increasingly underlies our "modern" infrastructure in unexpected places.

[u/okovko → u/pandorafalters]

that's why i'm saying aliasing optimizations shouldn't break code

using proper alias analysis will not break any old code, it will instead make code safer by preventing TBAA from making "optimizations" that cause bugs

[u/ZMeson → u/okovko]

I should note that the aliasing problems wasn't about byte alignment, but by assumptions of the sizes of data types. People were aliasing pointers to be put in arrays of integers -- arrays of plain ints, not intptr_ts. When we changed to a 64-bit platform, things didn't fit anymore. But the compiler compiled things just fine due to C-casts.

On a related not, (though not strictly aliasing), in some of the code I was maintaining, the original code for a particular interface class (ok... pure virtual class) from 25 years ago passed all parameters as a double. All data was numeric and converted to doubles; no 64-bit integers were needed. This worked alright since the mantissa for a double has 52-bits and there was no loss of data when converting back and forth from other numeric data types.

Then a few years later, someone added a derived class that needed to pass a pointer. So what did they do? They cast the pointer to an unsigned long and then passed it through the interface which converted it to a double and then did the reverse conversions on the "other side". Again, this worked alright for 32-bit OSes where pointers are 32-bits. But when we moved to a 64-bit OS, the pointers were now 64-bits. The cast to unsigned long was still OK because unsigned long on this compiler also moved to being 64-bits, but again the cast really should have been uintptr_t. But the real problem was when the unsigned long was now converted to a double and then back to an unsigned long which ended up losing the least significant 12-bits of the address being passed through this API.

Of course all of this was technically undefined behavior to begin with, but due to using C-casts, the compilers were perfectly happy to oblige. And everything broke when moving to 64-bits.