On 11/27/18 10:31 PM, Steven Watanabe via Boost wrote:
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.
Sure, that's my point. I was merely pointing out that there's no "choice" to make.
A correct C++ program should never do it.
I wouldn't assume about user's code.
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.
Having the wrap semantics would be useful, at least for being able to portably detect an overflow. That ability alone allows to implement whatever other behavior you might need. OTOH, having overflow undefined doesn't allow you to do anything with it.
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.
Until the language mandates two's complement signed integers (in the yet-to-come C++20), I don't think there is a correct way. At least nothing easy enough comes to mind.