3 ms·
> treating UB as something you'll see frequently in your career Sure it is! I'm not talking about skills: everybody writes UB, at any time. I'm talking about
by pif 2y ago
> treating UB as something you'll see frequently in your career
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!
- shadowgovt 2y agoIf that is your position, it makes sense. 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).
- pif 2y agoJust to be clear, I don't dislike this post for showing practical examples of UB. I'm just afraid that readers could take the wrong path and reason "This compiler does so-and-so, now I know how to better protect my current code", instead of the correct path of "Undefined means that I don't have the right to any expectation, thus I'll try and improve the portability of my algorithm". Maybe I did not choose my words properly, I apologise.