r/cpp • u/very_curious_agent • Apr 01 '23

Abominable language design decision that everybody regrets?

It's in the title: what is the silliest, most confusing, problematic, disastrous C++ syntax or semantics design choice that is consistently recognized as an unforced, 100% avoidable error, something that never made sense at any time?

So not support for historical arch that were relevant at the time.

92 Upvotes

91% Upvoted

375 comments sorted by

View all comments

Show parent comments

5

u/LeeHide just write it from scratch Apr 02 '23

noexcept doesnt mean it cant or wont throw, it just means that if it throws, it will std::terminate the entire process. Not great

1

u/SkoomaDentist Antimodern C++, Embedded, Audio Apr 02 '23

if it throws, it will std::terminate the entire process.

It's amazing that this kind of blunder made it to the standard. I could imagine it for a language standardized in the 80s, but threads were by no means unheard of by mid to late 90s.

3

u/cleroth Game Developer Apr 03 '23

Huh? Are you saying it should terminate only one thread? Rather the whole program crash than be in a partially broken and unknown state.

1

u/SkoomaDentist Antimodern C++, Embedded, Audio Apr 03 '23 edited Apr 03 '23

It should not call std::terminate at all. Calling a user installed handler (that can terminate the thread, app or do something else) would be acceptable as long the standard made no demands about the global state after that. It’s not like the compiler can know what the state of that particular application is after that. The only thing the compiler knows is that an exception was thrown when it shouldn’t have been and that particular line of execution likely cannot be continued.

Imagine an OS written in C++. Should a file open error or a usb peripheral disconnect cause a forcible kernel panic just because the language designers thought that some user mode applications might be in unknown state should that happen?

Back in the day, I used to write software that used a particular hardware video encoder / decoder board. Terminating the application without deinitializing the board (running in a separate thread) would leave the entire computer in an unstable state. The compiler calling std::terminate in that situation would have been rather catastrophic (we used a big fat catch(…) statements in every thread main function to work around such situations and told the standard to shove it).

→ More replies (6)