Hacker News new | ask | show | jobs
by camblomquist 728 days ago
C++ has an absurd amount of UB to the point where there's an entire thought exercise devoted to how malicious a compliant compiler can be (Hell++.) There are things that are allowed and even common in C but UB in C++ (union type punning,) and things that people reasonably can assume would work but are UB anyway (signed integer overflow.) Then you have weird edge cases like assigning the return value of a two argument std::max involving temporaries to a reference. There are so many UB foot guns, no reasonable developer can be expected to keep track of them all.
3 comments

> things that people reasonably can assume would work but are UB anyway (signed integer overflow.)

Since when is it reasonable to assume that?

> Then you have weird edge cases like assigning the return value of a two argument std::max involving temporaries to a reference

You have a reference to a temporary. Reference lifetime extension is a thing. No UB there. Completely defined and supported.

When all hardware built for decades uses two's complement arithmetic and even the standards bodies have noticed this (e.g. https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2218.htm) it's not remotely necessary to assume that overflowing a signed integer is undefined behaviour. It's totally defined exactly what that instruction is going to do on any hardware any electrical engineer is willing to build.

However, some benchmarks use iteration on a signed integer, and assuming that loop terminates makes it slightly faster, so in order to retain that marginal advantage over other languages, signed iteration shall be assumed to never overflow.

This is very typical of the C++ experience.

That's not why it's ub. It's ub to allow compilers to optimize x*2/2 to just x. If you want overflow, you can use unsigned, which has been defined to follow 2's complement semantics for quite some time.
> things that people reasonably can assume would work but are UB anyway (signed integer overflow.)

No, they cannot. You don't have the right to make any assumption about integer overflow in C.

Most of the whining about UB is from people who still refuse to accept that you don't have the right to think about your processor family once you write in any language that is not assembly.

Cannot find any articles discussing Hell++. Is it something specific? The thought seems very interesting and I'd like to read about it if you have any links :-) Thanks!
I'm not sure about Hell++, but DeathStation 9000 is a "common" jocular name for a hypothetical system which is as pathological as possible with respect to implementation definined and undefined behavior.
Honestly might just be a Discord in-joke on a C++ server as I can't find much specific either. Sorry for misleading!