Path: csiph.com!news.mixmin.net!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c++ Subject: Re: To C or not to C++ Date: Thu, 25 Aug 2022 12:14:09 -0700 Organization: None to speak of Lines: 63 Message-ID: <87h720kuf2.fsf@nosuchdomain.example.com> References: <2868500762@darkrealms.ca> <87iln0owgr.fsf@nosuchdomain.example.com> <87lerte0qb.fsf@nosuchdomain.example.com> <87sflmszgi.fsf@bsb.me.uk> <87wnaxsofv.fsf@bsb.me.uk> <87r115sn88.fsf@bsb.me.uk> <878rndy1wg.fsf@nosuchdomain.example.com> <87wnaxqsfy.fsf@bsb.me.uk> <87ilmgw82w.fsf@nosuchdomain.example.com> MIME-Version: 1.0 Content-Type: text/plain Injection-Info: reader01.eternal-september.org; posting-host="a042aa527780c44e7e71460682553b9b"; logging-data="3906412"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19eeL8C8Ep93xicgI2HpM1R" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) Cancel-Lock: sha1:YeO/xhE1lE6AsEmcDyM9SVXQzaA= sha1:Ex26rWiO5uY/If2MRDH/jQ8vBi8= Xref: csiph.com comp.lang.c++:86077 David Brown writes: > On 25/08/2022 19:23, Keith Thompson wrote: >> David Brown writes: >>> On 24/08/2022 22:48, Ben Bacarisse wrote: >>>> Keith Thompson writes: >> [...] >>>>> C23 will make bool, false, and true keywords. >>>>> >>>>> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n3047.pdf >>>> I didn't know that, but I am not surprised because of the new course >>>> C >>>> is taking. I hope it does not run aground... >>>> >>> >>> Some of the C23 changes are obvious and practical, such as "volatile >>> semantics for lvalues" (embedded developers have been relying on this >>> for decades, so it's nice to see it standardised), and the >>> standardisation of "#warning" (again, something that people have used >>> for decades). >>> >>> But there has definitely been a change in the principles. C23 makes >>> "bool" the type and keyword, with "_Bool" as the "alternative >>> spelling". Similarly we now have "static_assert", "alignas", etc. >>> "void foo();" now means "void foo(void);". There are many things like >>> this that arguably make C a slightly better and neater language, and >>> will not harm anyone who has been writing decent C99 code over the >>> past couple of decades. But C has a history older than that - and >>> backwards compatibility is a prime reason the language is still alive >>> and kicking. >>> >>> I suppose that we can rely on gcc to follow the fine tradition of >>> supporting old, outdated and dangerous constructs when invoked without >>> specific standards or warning flags - I expect it to still work with >>> code that has "typedef int bool;" for a long time to come. >> Remember that C99 removed implicit int, which in principle broke a >> lot >> of existing code. Most compilers continued to accept implicit it in >> some mode, perhaps with a non-fatal warning. >> > > Yes, that is an example of gcc supporting old and dangerous constructs > even when nominally using standards that disallow it. > >> Code that uses bool, false, and true as identifiers is going to be a >> little trickier to handle in lexical analysis and parsing. > > I expect the gcc folks will figure out a way to handle it - at least > in cases where the "homemade" bool type and values are directly > compatible with the "real" type and values. (For the type, that would > really just mean manually doing "typedef _Bool bool;" or "#define bool > _Bool", since alternatives like enumerations, int, or char do not have > the same semantics.) I wouldn't expect (or want) a compiler to handle a user-defined bool differently depending on whether it thinks it's compatible with the built-in bool. But this discussion probably belongs in comp.lang.c anyway. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips void Void(void) { Void(); } /* The recursive call of the void */