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?