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 11:36:20 -0700 Organization: None to speak of Lines: 63 Message-ID: <87lerckw63.fsf@nosuchdomain.example.com> References: <2868500762@darkrealms.ca> <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> <87a67sy5u2.fsf@bsb.me.uk> <392fc8fe-b516-434c-8962-c11e2154f4c6n@googlegroups.com> <87y1vcwo4q.fsf@bsb.me.uk> <6aeee22b-9030-481e-86cb-4a47c6746f0bn@googlegroups.com> <87mtbsw8vf.fsf@nosuchdomain.example.com> <9af97d69-57b6-4b58-bd51-e7557692b3cen@googlegroups.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="U2FsdGVkX1/Lz7cE1N7K/xhDAIs2fgGt" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) Cancel-Lock: sha1:AQI2Rd/IgU7jjs4VCaCmWF51UVw= sha1:ZEPHm/EiitzglZ6M/SBwN8Z26UM= Xref: csiph.com comp.lang.c++:86073 Malcolm McLean writes: > On Thursday, 25 August 2022 at 18:06:45 UTC+1, Keith Thompson wrote: >> Malcolm McLean writes: >> [...] >> > Computer science people would tend to think that it's important to have >> > a boolean type, because a lot of logic works on values which are inherently >> > true or false. Practical programmers would tend to say that it's not, because >> > most hardware won't support it. You will of course find exceptions. >> Many practical programmers would tend to say it's important to have a >> boolean type because it makes it easier to write clear code. (Some >> probably prefer to use zero and non-zero rather than explicit bool, >> false, and true.) >> > It does document that a value is logically bi-valued. So we can enable or disable > a button, but we can't have it in a half-enabled state. However the problem is > that when you look at C++ code which uses booleans, it's not clear what is > being passed > e.g. if you see > Button mybutton("OK", &rect, true); > Obviously this is creating a button. Obviously it's got the display text "OK". Obviously > rect is some sort of rectangle containing the position. But what is "true"? > If we make enabled / disabled an enum, then it's more clear what the code is doing. Agreed -- but what does that have to do with what we were discussing? You were talking about hardware support. The same considerations apply to a built-in boolean type or to a 2-element enum. >> Why would a "practical programmer" care whether there's direct hardware >> support for bool? If the compiler handles it correctly, it just works. >> In a very real sense, all hardware supports booleans, with more or less >> work required by the compiler. >> > Well one issue is whether if (flag == true) works as expected. If the hardware supports > 1 bit types, then it must work, because flag cannot have any bit pattern other than > bit clear / bit set. If bool is something provided by software, and the underlying type > is an integer, then it might hold unexpected values. > A theoretical person doesn't really have to worry about this, because in his world, all > bools are initialised to 1 or 0 and all operations on them yield 1 or 0. In the practical > programmer's world, things can get more messy, because some of the code might > be written in another language, for example. First off, why would you write `if (flag == true)` rather than `if(flag)`? But for a boolean type that's built into the language, like C's _Bool or C++'s bool, none of that is an issue in the absence of memory corruption. Conversions to bool always yield false or true (0 or 1). If some of the code is written in another language, then *of course* you have to make sure that anything converted to a native boolean is normalized. Anything that stores a value other than 0 or 1 in a C or C++ boolean object is buggy, and needs to be fixed. None of this has anything to do with some distinction between theoretical and practical programmers. Sometimes I'm a theoretical programmer, and sometimes I'm a practical programmer. In either role, I care that something is supported by the combination of the hardware and the compiler. As long as the compiler does its job, it works. -- 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 */