Re: [boost] Current Guidance on Compiler Warnings?

Subject: Re: [boost] Current Guidance on Compiler Warnings?
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2018-11-27 19:31:30

AMDG

On 11/27/2018 11:58 AM, Andrey Semashev wrote:
> On Tue, Nov 27, 2018 at 7:18 PM Steven Watanabe via Boost
> <boost_at_[hidden]> 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