> Given that reality, knowing what your compiler will do with UB ...
The more you refuse to accept undefined behaviour, the more it will hurt when it will bite you!
Stop turning around the problem and fix your code.
The more you refuse to accept undefined behaviour, the more it will hurt when it will bite you!
Stop turning around the problem and fix your code.
Given that, plus the reality that we insist on continuing to write a million lines of C++, treating UB as something you'll see frequently in your career is probably the reality-based behavior.
Sure it is! I'm not talking about skills: everybody writes UB, at any time. I'm talking about attitude: when you see UB, you must strive to remove it, not to protect it!
I didn't recognize it as your position because you presented "Developers must avoid UB in their code, at all costs" as supporting the preceding statement "This post has no point;" if your point is "developers should remove UB when they see it," then the point of this post is helping people see what UB looks like at the next layer of abstraction down as an aid to identifying and removing it.
(The C++ standard is over 2,000 pages. It's impractical to believe developers see UB by reading the C++ source code; most is identified by an application behaving incorrectly followed by inspection of the machine code to understand where the developer's assumptions about the C++ specification failed to match with the actual specification).
Maybe I did not choose my words properly, I apologise.