Xref: utzoo comp.lang.c++:13824 comp.std.c++:947 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uupsi!sunic!news.funet.fi!fuug!fuug.fi!pena From: pena@brainware.fi (Olli-Matti Penttinen) Newsgroups: comp.lang.c++,comp.std.c++ Subject: Re: Boolean confusion Message-ID: Date: 30 May 91 12:27:56 GMT References: <332@nazgul.UUCP> <1991May29.145100.18519@watson.ibm.com> <1991May29.171209.14760@neon.Stanford.EDU> <1991May30.060200.6590@lth.se> Sender: usenet@fuug.fi (USENET News System) Distribution: comp.lang.c++ Organization: Brainware Oy, Espoo, Finland. Lines: 51 In-Reply-To: dag@control.lth.se's message of 30 May 91 06: 02:00 GMT Nntp-Posting-Host: brainw.brainware.fi In article <1991May30.060200.6590@lth.se> dag@control.lth.se (Dag Bruck) writes: void f(int); void f(boolean); I also think a boolean data type would increase type safety in C++, at least the way I program (:-). I once tried to implement `class boolean' and failed. Firstly there was a performance problem, which I think good compilers could overcome. Secondly, I don't think I gained anything in type safety and little in convenience: to be at all useful I needed implicit type conversions int->boolean and boolean->int. I think a boolean data type should _not_ be another kind of integer (at least eventually) which can be implicitly converted to/from int. It should instead be a unique enumerated type, but that doesn't work until all standard functions (e.g., operator == (int, int)) return a boolean and not an int. I partly agree. It would be nice, if operator==(T,T) would return a truly boolean value. On the other hand, it is possible to achieve the same type safety if one implements not only a class boolean, but classes real, integer, string, and what not, as well. That would of course introduce a rather severe performance penalty, however. If only current compilers did a better job in optimizing common sub-expressions involving inlined access member functions and such... :-( I know of at least one project, in which the group (they used Ada) redefined practically everything, and to some extent succeeded. They did peculiar things like had an "enum boolean { true, false, i_dont_care, i_dont_know}" type of a construct. Summa summarum: once again we face a consept that could be incorporated to the language and indeed would fit in well, but without which we can manage. IMHO, that means we shouldn't have it. Especially, since no current library can support it. Dag Br!"uck -- Department of Automatic Control E-mail: dag@control.lth.se Lund Institute of Technology P. O. Box 118 Phone: +46 46-104287 S-221 00 Lund, SWEDEN Fax: +46 46-138118 ==pena -- Olli-Matti Penttinen | "When in doubt, use brute force." Brainware Oy | --Ken Thompson P.O.Box 330 +---------------------------------- 02151 ESPOO, Finland Tel. +358 0 4354 2565 Fax. +358 0 461 617