| Deutsch English Français Italiano |
|
<44msie3mrn.fsf@be-well.ilk.org> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!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: Lowell Gilbert <lgusenet@be-well.ilk.org> Newsgroups: comp.lang.c Subject: Re: constexpr keyword is unnecessary Date: Mon, 04 Nov 2024 12:57:16 -0500 Organization: A noiseless patient Spider Lines: 37 Message-ID: <44msie3mrn.fsf@be-well.ilk.org> References: <veb5fi$3ll7j$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> <86cyjmuoop.fsf@linuxsc.com> <MFuTO.299995$kxD8.185214@fx11.iad> <86r07ru289.fsf@linuxsc.com> MIME-Version: 1.0 Content-Type: text/plain Injection-Date: Mon, 04 Nov 2024 18:57:17 +0100 (CET) Injection-Info: dont-email.me; posting-host="0e760524fb0c36537b88a07cd124e3fe"; logging-data="1122882"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19yBoND5E9iqO3peh+QabC3" User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:S0CIViogNZoGGmErdEqXOd8Ol0I= sha1:YqwKCxCXsWOq4c88YTb2df4xfPA= Bytes: 2949 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. 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. Be well. -- Lowell Gilbert, embedded/networking software engineer http://be-well.ilk.org/~lowell/