Re: constexpr keyword is unnecessary

Lowell Gilbert <lgusenet@be-well.ilk.org> writes:

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

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

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

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

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.

>
Not in so many words, no.  Here is one that I have seen work well
in recent years:  the code must compile without warnings.  The
usefulness of this policy is strictly in making sure that any new
warnings are immediately noticed and considered, but are not an
ongoing distraction.

You don't say what warning conditions are tested, or who gets to
decide which conditions are included in the set to be satisfied.

The question of how to shut up a warning that is truly innocuous
is not part of this policy.  In my own opinion, it will often
require its own policy.  That is a separate topic, because it can
quite reasonably vary depending on a number of factors in the
development environment, most notably the compiler itself.

ISTM that what can be done to remove a warning must be part of
the policy of not allowing warnings.  If there is no statement
about what can be done to remove warnings then the "no-warning"
policy is toothless.  In any case no policy for this aspect is
given, and what I'm looking for is a clear statement of policy.
Was that somehow not obvious from my previous comment?