Path: csiph.com!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch
Newsgroups: comp.lang.c
Subject: Re: constexpr keyword is unnecessary
Date: Sat, 26 Oct 2024 21:58:46 -0700
Organization: A noiseless patient Spider
Lines: 31
Message-ID: <86cyjmuoop.fsf@linuxsc.com>
References: <877ca5q84u.fsf@nosuchdomain.example.com> <87y12jpxvl.fsf@nosuchdomain.example.com> <87plnvpgb9.fsf@nosuchdomain.example.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Sun, 27 Oct 2024 05:58:47 +0100 (CET)
Injection-Info: dont-email.me; posting-host="d3e5dc7bdb0f10980bd7d09bc656fcce"; logging-data="133242"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+l3cFBLh+LWz5Pv9jNeMAXGLStX15DZxw="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:V3pFbW2SuX+v9ZYhGD/QWb7PMYY= sha1:xe++FlIE96d9STK76pUsf6RED4Y=
Xref: csiph.com comp.lang.c:388747
scott@slp53.sl.home (Scott Lurndal) writes:
> Janis Papanagnou 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?