Re: [boost] Current Guidance on Compiler Warnings?

Subject: Re: [boost] Current Guidance on Compiler Warnings?
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2018-11-27 20:02:58

On Tue, Nov 27, 2018 at 11:14 AM Daniela Engert via Boost <
boost_at_[hidden]> wrote:
>
> Am 27.11.2018 um 19:58 schrieb Andrey Semashev via Boost:
>
> > 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. And this
> > is the worst thing because it is a constant source of bugs and is not
> > useful to the programmer. 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. 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.
>
> Exactly my position in this regard. If only there were a signed integral
> type with modulo arithmetic in C++. In other words: the raw underlying
> hardware implementation without the UB semantics demanded by C++.

The result would be:

1) Compilers would generate less optimal code, as demonstrated by this
discussion.
2) You will still get a mathematically incorrect result most of the time.