Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!fernwood!lia!jgro From: jgro@lia (Jeremy Grodberg) Newsgroups: comp.lang.c++ Subject: Re: Boolean confusion Message-ID: <1991May30.215946.4208@lia> Date: 30 May 91 21:59:46 GMT References: <332@nazgul.UUCP> Reply-To: jgro@lia.com (Jeremy Grodberg) Distribution: comp.lang.c++ Lines: 66 In article <332@nazgul.UUCP> bright@nazgul.UUCP (Walter Bright) writes: >In article haydens@natasha.juliet.ll.mit.edu (Hayden Schultz) writes: >/So my question is, how can I choose one definition (my own, or someone >/else's) for boolean variables, and still remain insulated from the sea >/of boolean definitions in assorted include files? >/What's the best way to do this? > >After years of fiddling around with various schemes myself, the most practical >one I came up with is just use int: > > /********************* > * Test some quantity. > * Returns: > * 0 False > * !=0 True > */ > > int func(); > >I've gone through my code over time and have eliminated all the logical, bool, >boolean, BOOL, etc. clutter. Although the above solution seems boring and >inelegant, it works suprisingly well, given that it mimics C's idea of what >is true and what is false. > >Note that you also need to get rid of any TRUE or FALSE #define's. Remember to >always test for 0 or !=0. > >(Some other battle-scarred old C programmers have told me that they have > eventually come to the same conclusions.) I agree about using int for booleans, but I disagree about getting rid of TRUE and FALSE. I, like a lot of programmers, skimp on writing comments. To make up for it, I try to write self-documenting code, through appropriate use of varible and function names. TRUE and FALSE make it clear, without comments, that a boolean value is being returned. Also, since many (bad) compilers in my early C programming days required TRUE to be !FALSE (which could be 1, 0xFF, 0xFFFF, or something else) for boolean arithmetic to work properly, I get worried about simply returning 1 for true. Using TRUE and FALSE allows me to avoid problems like that. I would sooner give up NULL then TRUE or FALSE. From my C experience, I always include: #ifndef FALSE #define FALSE 0 #endif #ifndef TRUE #define TRUE !FALSE #endif You may complain about using !FALSE instead of (!FALSE), but it has never caused me a problem. Many (bad) compilers in my early C programming days required TRUE to be !FALSE for boolean arithmetic to work properly, so I still use that. If you are worried about getting some incompatible TRUE or FALSE, you can replace the #ifndefs with #undefines. You only get what ANSI promises (and not always that), and ANSI only promises int's for booleans, so that's what I use. It may mean not discovering compiler problems, but my job is to get programs to work, not to fix compilers. -- Jeremy Grodberg "Show me a new widget that's bug-free, and I'll show jgro@lia.com you something that's been through several releases."