Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
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: <veb5fi$3ll7j$1@dont-email.me> <877ca5q84u.fsf@nosuchdomain.example.com> <vf0ijd$3u54q$1@dont-email.me> <vf0l98$3un4n$1@dont-email.me> <vf1216$p0c$1@dont-email.me> <87y12jpxvl.fsf@nosuchdomain.example.com> <vf1d2o$2hjk$1@dont-email.me> <87plnvpgb9.fsf@nosuchdomain.example.com> <vf2sm8$deou$1@dont-email.me> <vf7m4s$1d8mj$1@raubtier-asyl.eternal-september.org> <vf86uc$1fvt3$1@dont-email.me> <vfit29$3obkb$1@dont-email.me> <vfj5up$3q2lf$1@dont-email.me> <vfjcbu$3r4g7$1@dont-email.me> <ExbTO.14733$tnK2.11037@fx04.iad>
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=
Bytes: 2877

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?