lysdexic

Some people also feel strongly about topics they are very familiar with 🙂. I have experienced my fair share of undefined behaviour in C++ and it has never been a pleasant experience.

If you had half the experience you claim to have, you'd know that code that triggers UB is broken code by definition, and represents a bug that you introduced.

It's not the language's fault that you added bugs to the code. UB is a red herring.

Sure, sometimes use of undefined behaviour works (...)

You missed the whole point of what I said.

By definition, UB does not work. It does not work because by design there is no behavior that should be expected. By design it's up to the implementation to fill in the blanks, but as far as the language spec goes there is no behavior that should be expected.

Thus, code with UB is broken code, and if your PR relies on UB then you messed up.

Nevertheless, some implementations do use UB to add guardrails to typical problems. However, if you crash onto a guardrail, that does not mean you know how to drive. Do you get the point?

Where he gives plenty of examples of UB resulting in the compiler optimizing away safety and introducing security vulnerabilities silently.

That's the bit that those who parrot on abot UB get entirely wrong, and yet cling to it if it was something meaningful.

Let's make this absolutely clear: any code you write that triggers UB is a a bug you introduced. Your complains about UB boil down to blaming the language for bugs you created because you didn't knew what you were doing.

As you can configure compilers and static code analysis tools to flag UB as warnings or even errors, the discussion of using UB in your code is a discussion on incompetence. Complaining that a programming language purposely leaves out the specification of the behavior that broken code should have because you don't know what you're doing is the definition of a bad workman blaming his tools.

If you paid attention to the article you're quoting, you'd notice that even the author makes it quite clear that programs with UB only "appear to work". That boils down to the definition of UB, and the reason why every single developer in the world who had any intro to C or C++ experience knows quite well that UB means broken code. Why is it hard for you to understand this?

Each implementation that exhibits different behavior doubles the amount of testing needed to ensure cross-platform correctness.

Not really. The whole point of undefined behavior is that the standard intentionally leaves out any definition of behavior, or the program is already fundamentally broken.

If you insist on unwittingly using code that relies on undefined behavior, you're the one mindlessly writing broken code. It's not the standard's fault that you're adding bugs.

The irony is that compiler implementations also leverage undefined behavior to save you from yourself and prevent programs to crash when they stumble upon the mess you've done with the code.

what is the usecase for going beyond maxint?

There are many examples of applications that leverage integer overflow, either wrapping around or saturating values.

What do you mean wrong “already”?

This is one of the problems in these discussions about undefined behavior: some people feel very strongly about topics they are entirely unfamiliar with.

According to the C++ standard, "undefined behavior may be expected when this document omits any explicit definition of behavior or when a program uses an erroneous construct or erroneous data." Some examples of undefined behavior still lead to the correct execution of a program, but even so the rule of thumb is to interpret all instances as wrong already.

It violates the principle of least surprise.

It really doesn't. I recommend you get acquainted with what undefined behavior is, and how it's handled by developers.

You don’t expect the compiler to delete your bounds checking etc.

By design, undefined behavior has a very specific purpose. Newbies are instructed to consider code that leads to undefined behavior as a bug they introduced. For decades compilers and static code analysis tools can detect and flag undefined behavior as errors in your code.

As I said before, sometimes it seems clueless developers parrot on about "undefined behavior" as some kind of gotcha although they clearly have no idea what they are talking about. Sometimes it sounds like they heard it somewhere and just mindlessly repeat it as if it meant something.

The way c and c++ define and use UB is like finding an error at compile time and instead of reporting it, the compiler decides to exploit it.

What are you talking about? Compilers can and do flag undefined behavior as errors. I recommend you read up on the documentation of any compiler.

Also, I don't think you fully understand the subject. For example, as an example, some compiler implementations leverage UB to add failsafes to production code such as preventing programs from crashing when, say, null pointers are dereferenced. We can waste everyone's time debating whether null pointers should be dereferenced, but what's not up for discussion is that, given the choice, professional teams prefer that their code doesn't crash in users' machine if it stumbles upon one of these errors.

The most asinine thing i encountered is that the bracket operator on std::map writes 0 value if the key is not found.

That's a "you're using it wrong" problem. The operator[] is designed to "Returns a reference to the value that is mapped to a key equivalent to key, performing an insertion if such key does not already exist. "

The "0 value" just so happens to be the result you get from a default initializer whose default initialization corresponds to zero-initialization.

If you want to use a std::map to access the element associated with a key, you need to either use at and handle an exception if no such key exists, or use find.

Should focus on getting rid of undefined behavior.

What problem do you believe is presented by undefined behavior?

Not sure exactly what you mean, could you elaborate or rephrase?

There is nothing to rephrase. I asked what problem do you think that undefined behavior poses. That's pretty cut-and-dry. Either you think undefined behavior poses a problem, and you can substantiate your concerns, or you don't and talking about undefined behavior being a concern is a mute point.

my point was that I was able to find answers for everything else before I had to resort to posting a question.

That's not a SO problem per se. Some projects do use SO as their semi-official customer support channel, but in general posting a question on SO is not supposed to be better than posting a question on Reddit: you get what you paid for.