Re: constexpr keyword is unnecessary

scott@slp53.sl.home (Scott Lurndal) writes:

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>

scott@slp53.sl.home (Scott Lurndal) writes:
>

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>

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.

>
Yes, we have a similar policy.  Works well.  In the odd case where
one cannot eliminate the warning, a simple compiler option to not
test that particulary condition for that particular compilation
unit is a straightforward solution.

>
So the actual policy is to fix all warnings except in
cases where it's inconvenient to fix them?

>
No, I never said that.

I didn't say you did.  I asked a question because I didn't see
any clear statement of what the policy is that was being
followed.  And I still haven't.