AMDG On 11/27/2018 11:58 AM, Andrey Semashev wrote:
On Tue, Nov 27, 2018 at 7:18 PM Steven Watanabe via Boost
wrote: On 11/26/2018 03:57 PM, Gavin Lambert via Boost wrote:
<snip> The most important feature of undefined behavior is that it allows you to choose the behavior that you want instead of hard-coding it into the program.
I disagree. I think, the choice is only there as long as you target a specific language implementation, or the very few of them which offer the choices you care about. If you're trying to write portable code, like we most often do in Boost, for example, you really don't have a choice and have to assume the behavior is really undefined.
You don't "assume that it's undefined." It /is/ undefined. A correct C++ program should never do it.
And this is the worst thing because it is a constant source of bugs and is not useful to the programmer.
My point is that it's a bug regardless. Your program is wrong regardless of whether it's formally undefined behavior or just gives the wrong answer. The only difference is in how serious the symptoms are and what tools are available for finding the problem.
The ironic thing is that you can't even check for a possible overflow in portable C++ since "it doesn't happen" by the language rules and the compiler is allowed to subvert or completely discard your checks.
That only happens if you write the check incorrectly.
Over the years I have grown a habit of avoiding signed integers where not genuinely needed.
On the topic of performance gains, yes, there are some, but I'm not really convinced they are significant enough in general and can't be achieved by careful coding where truly needed.
In Christ, Steven Watanabe