Newsgroups: comp.lang.c++ Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!van-bc!ubc-cs!uw-beaver!mit-eddie!xn.ll.mit.edu!xn!haydens From: haydens@natasha.juliet.ll.mit.edu (Hayden Schultz) Subject: Boolean confusion Message-ID: Sender: usenet@xn.ll.mit.edu Organization: M.I.T. Lincoln Lab - Group 42 Distribution: comp.lang.c++ Date: 23 May 91 10:32:33 I've been browsing through include files and it seems that everyone in the world who ever created a C++ include file created some definition to support boolean variables. I've seen BOOL bool Bool BOOLEAN boolean Boolean bool_t BOOL_T, ... Some are #defines, some are typedefs. Some folks like to associate them with char, unsigned char, int, long, or enum. Some packages (like XView) must have used a random number generator to decide which definition would be used for each separate include file-- I doubt that anyone could be that inconsistant unless it was deliberate. 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? For that matter, am I insulated even without a boolean definition of my own? I suppose I could pick some extreamly unlikely name for my boolean variable type, but I really don't want to. One reason is that it makes code so much clearer to have clear straighforward class and type names. The best I can think of right now is to always include "foreign" include files first, then my own. In my own include files I can do something like: #ifdef Bool #undef Bool #endif typedef enum {FALSE, TRUE} Bool; I suppose that I could still take a hit from a macro, or inline function. I don't think I'm immune from name space conflicts either. The biggest thing I'd like to avoid is having the same class have different sizes in different include files due to include file interference. What's the best way to do this? Thanks, Hayden Schultz (haydens@juliet.ll.mit.edu) MIT Lincoln Lab (617) 981-3685