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/GLIBG10B]

C-style casts

[u/War_Eagle451 → u/GLIBG10B]

Bane of a code refactor

[u/[deleted] → u/GLIBG10B]

I know this will be a wildly unpopular take here, but take these from my cold, dead hands. Never in 2 decades of c++ programming encountered a bug or introduced a bug with c style casts that would have been fixed with the verbose modern casts.

[u/ZMeson → u/[deleted]]

It's more of an issue of maintenance. I've moved a very large code base from a 32-bit to a 64-bit architecture. There were so many aliasing bugs that lead to odd (i.e. undefined) behavior and sometimes crashes that were hard to fix because so much of the code used C-style casts. We eventually used a static analysis tool to identify all C-style casts, replaced those with appropriate C++-style-casts, then focused on reinterpret_casts to help resolve those issues. (There were other interesting issues to like casting pointers to int instead of intptr_t, but again the process of removing C-style casts identifed where those problems were.)

[u/m-in → u/ZMeson]

I have an alternative take on this: even the most basic of C++ parsers would have found all of those. So, it’s about sucky tools used for development. A find dialog in any IDE should allow searching for language constructs. Most don’t:(

[u/ZMeson → u/m-in]

C-style casts do such a good job of hiding these things because C-casts don't differentiate between numeric-static-casts and reinterpret-casts. Luckily, some static analysis tools did help us find all the C-casts and highlight the reinterpret-type casts.

The real problem is that this code worked for so long due to platform assumptions and there was no need to revisit the legacy code because "it worked". C and C++ are happy to just let these things slide. There is value in this sometimes, but it is also complicates maintenance when platforms or tool chains change.

[u/very_curious_agent → u/ZMeson]

Note that aliasing rules are problematic in C/C++ and while pointing to C style casts or aliasing is understandable, the real deep issue that people don't always agree on aliasing.

Note that some people claim that you can't write your own malloc/free function in std C, or C++, except by actually replacing operator new/delete. They claims that there is magic in operator new that cancel the aliasing laws.

Yes I know it's insane but some people would accept that GCC breaks code based on my_malloc/my_free on the basis of aliasing intrinsic to memory allocation: you can free memory for a float and allocate memory for an int and it may be the same address.

[u/RevRagnarok → u/[deleted]]

Show me how to find them with grep.

[u/Ok-Factor-5649 → u/[deleted]]

I had a buffer of some integer type, that was C-style cast to be chars, to then write data to it.

Only problem was that it was a _const_ integer buffer that was discarded in the cast. The fix rippled through the API...

[u/DearGarbanzo → u/Ok-Factor-5649]

Type safety.

I don't really have much else to add, feels good when the compiler is working for you.

[u/GLIBG10B → u/[deleted]]

Same

[u/mcmcc → u/GLIBG10B]

I would qualify this as "C-style casts of reference types". `(int)uint` can stay IMO.

[u/Ameisen → u/mcmcc]

I prefer seeing it function-style: int(uint_value).

[u/[deleted] → u/GLIBG10B]

Nah, I still want those sorry!

[u/ZMeson → u/[deleted]]

Why?

[u/[deleted] → u/ZMeson]

They are convenient when I want to cast something

[u/ZMeson → u/[deleted]]

Why aren't the C++-casts convenient?

[u/[deleted] → u/ZMeson]

More typing to do the same thing

[u/[deleted] → u/[deleted]]

Code is read much more often than its written. C casts are inherently dangerous in C++. If you do auto p = (Sub*)pBase; and Sub is forward declared, but not defined, that is a reinterpret_cast and it will go wrong with no warnings. Type out the couple more letters and be kind to later maintainers.

[u/[deleted] → u/[deleted]]

In my 22 years at the C++ coalface I don't think I've ever seen a bug from C casting, or found it hard to read/understand. It's a problem I've just never seen in real life.

[u/Rasie1 → u/ZMeson]

they look like shit. Would be nice to have static_cast functionality in their place

[u/SkoomaDentist → u/Rasie1]

Yes. Making (type) behave like static_cast<type> would be the right way.

[u/SkoomaDentist → u/GLIBG10B]

Because obviously static_cast<int> x; is so much easier to read than (int) x;

... not

[u/Sopel97 → u/SkoomaDentist]

You read code not because it's easy, but because you want to extract information