Xref: utzoo comp.lang.c++:13826 comp.std.c++:948 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!paperboy!hsdndev!dartvax!eleazar.dartmouth.edu!npw From: npw@eleazar.dartmouth.edu (Nicholas Wilt) Newsgroups: comp.lang.c++,comp.std.c++ Subject: Re: Boolean confusion Message-ID: <1991Jun2.021100.7024@dartvax.dartmouth.edu> Date: 2 Jun 91 02:11:00 GMT References: <1991May29.171209.14760@neon.Stanford.EDU> <1991May30.060200.6590@lth.se> Sender: news@dartvax.dartmouth.edu (The News Manager) Distribution: comp.lang.c++ Organization: Dartmouth College, Hanover, NH Lines: 24 Defining your own Boolean type (with #defines, typedefs, or classes, as you prefer) has advantages, but they are far outweighed by the problems introduced when someone tries to use your code (or, conversely, when you're trying to deal with code full of Booleans of one flavor or another). What happens when you try to make use of two libraries, one of which thinks Boolean is a "typedef int" and another which thinks Boolean is a class? You could go through renaming and reworking, but that shouldn't be necessary. C++ inherits a pretty reasonable treatment of integers as Boolean values from C (nonzero is True when evaluating, Boolean expressions evaluate to integer 1 or 0). It's portable, reasonably clean and flexible--for instance, there's no other way to stuff multiple Booleans into a single word, like you can with the : construct in C structures. A little less pretty than any of the ten thousand other ways people can think of to deal with Boolean values, but unlike any of those, it's standard. Overall, I think the disadvantages outweigh the advantages. I hate buying C source code and seeing Boolean defined explicitly. It gets ripped out as soon as a need develops to interface with it more than perfunctorily. --Nick npw@eleazar.dartmouth.edu