Re: constexpr keyword is unnecessary

On 26.10.2024 17:08, James Kuyper wrote:

On 10/26/24 10:07, Vir Campestris wrote:

>
I have in the past had coding standards that require you to fix all
warnings. After all, sometimes they do matter.

 
I disapprove of that policy. A conforming implementation is free to warn
about anything, even about your failure to use taboo words as
identifiers. While that's a deliberately silly example, I've seen a fair
number of warnings that had little or no justification.
The purpose of warnings is to tell you that there might be a problem. If
the compiler is certain that there's a problem, it should generate an
error message, not a warning. Therefore, treating warnings as if they
were error messages means that you're not doing your job, as the
developer, to determine whether or not the code is actually problematic.

We had such a null-warning policy as well (in a C++ context) and it
served us well.

But I agree that it depends (besides on the language) also on the
types of emitted warnings (and on the compilers used, where you
typically can also control types of emitted warnings and adjust the
default settings appropriately).

In my book it's better to respect warnings in the first place before
deciding to [sophisticatedly] disable any of them, or, while not have
them disabled, to have them inspected on every compile run (until you
ignore them uninspected due to boredom). It's especially important if
you're working with a team of programmers with manifold skill levels.
And for automated build processes we wanted a reliable binary decision
("pass" or "fail", and not "maybe"). It's probably even more an issue
in multi-platform/multi-compiler/multi-teams projects (which was our
typical project setting).

Janis