ANSI Do c No: X3J16/93-0143 ISO Do c No: WG21/N0350 Date: Septemb er 27, 1993 ++ Pro ject: Prog. Language C Reply To: Dag Bruc k [email protected] Extension prop osal: Bo olean data typ e 1 2 Dag Bruc k and Andrew Ko enig 1. Intro duction ++ The idea of a Bo olean datatyp e in C is a religious issue. Some p eople, particularly those coming from Pascal or Algol, consider it absurd that C ++ should lack suchatyp e, let alone C . Others, particularly those coming from C, consider it absurd that anyone would b other to add suchatyp e to ++ C . Why b other indeed? The main reason is that p eople who like suchtyp es often write header les that contain things like this: typedef int bool; class Mine { // ... }; bool operator==(const Mine &, const Mine &); Such a header le is just ne until someone else's header le says typedef char bool; If b oth header les used int, there would b e no problem, but trying to de ne bool as two di erenttyp es just won't work. ++ Several widely used C libraries, including X11 and InterViews, de ne a Bo olean datatyp e. The di erences in the de nitions of the Bo olean datatyp e create very real compatibility problems when mixing libraries from multiple sources. In principle, this problem could b e solved by agreeing on a single typ e de nition of bool as part of the standard library, just as NULL is part of 1 Author's address: Dynasim AB, ResearchPark Ideon, S-223 70 Lund, SWEDEN. E-mail: [email protected] 2 Author's address: AT&T Bell Lab oratories, 600 Mountain Avenue, Ro om 6D-416B, PO Box 636, Murray Hill, NJ 07974-0636, USA. E-mail: [email protected] 1 X3J16/93-0143 WG21/N0350 the standard C library.However, that approach has several signi cant disad- vantages when compared with the prop osal that follows. In particular, any prop osal that makes the Bo olean typ e a synonym for any other built-in typ e gives up the p ossibilityofoverloading on that typ e. On the surface, it is hard to b elieve that any compromise is p ossible between those extremes. After all, a language either has a Bo olean typeorit do es not. However, closer examination suggests that a middle ground might b e p ossible: a Bo olean typ e whose existence the programmer has the option to ignore. This prop osal shows how suchatyp e can work. It is the result of dis- cussions with a numb er of p eople, b oth in p erson and via electronic mail. Of course, any mistakes or misjudgments in this prop osal are ours alone. 2. Executive summary We prop ose the creation of a new built-in typ e called bool, with the following prop erties: bool is a unique signed integral typ e, just as the wchar_t is a unique unsigned typ e. There are two built-in constants of this typ e: true and false. Op erator ++ is de ned for bool; it always sets its op erand to true. This op erator is an anachronism, and its use is deprecated. A bool value may b e converted to int by promotion, taking true to one and false to zero. Anumeric or p ointer value is automatically converted to bool when needed. This is an anachronism, and its use is deprecated. When converting a numeric or p ointer value to bool, a zero value b ecomes false; a non-zero value b ecomes true. The built-in op erators &&, ||, and ! are changed to take bool values as their arguments and return bool results. The relational op erators <, >, <=, >=, ==, and != are changed to yield a bool result. Expressions used as conditions in if, for, while,ordo statements or as the rst op erand of a ?: expression, are automatically converted to bool. We b elieve this extension is upward compatible except for the new keywords bool, true, and false. 3. Rationale and examples Current practice A quickinvestigation of one computer system reveals that Bo olean datatyp es are quite common in widely used libraries. In the /usr/include area on one of our machines (bellman.control.lth.se), the de nitions of Bo olean in Table 1 can b e found. Various libraries also de ne true and false, see Table 2. The header les that do not rely on a de nition of Bo olean seem to b e part of the Sun op erating system. 2 X3J16/93-0143 WG21/N0350 curses.h #de ne b o ol char X11 #de ne Bo ol int gcc/X11 Multiple de nitions of Bo olean, dep ends on machine typ e etc. netap/appletalk.h typ edef int b o olean; tint rp c/typ es.h #de ne b o ol rp c/*.h Many uses of b o ol t nfs/nfs.h Uses b o ol t t tfs/tfs.h Uses b o ol sunwindow/rect.h #de ne b o ol unsigned sunwindow/sun.h typ edef enum fFalse = 0, True = 1g Bo ol; sunwindow/*.h Uses b o ol sunto ol/*.h Uses b o ol, at least as comment InterViews typ edef unsigned b o olean; NEWMAT matrices bool de ned as class or char, dep ends on compiler C++Views boolean de ned with typ edef sys/typ es.h (Solaris) typ edef 'd as enumeration Table 1. Current de nitions of boolean. curses.h #de ne TRUE 1 #de ne FALSE 0 X11/Intrinsic.h (same) gcc/X11/Intrinsic.h (same) netat/appletalk.h (same) pixrect/gtvar.h (same) sbusdev/audiovar.h (same) sunto ol/*.h (2 places) (same) sunwindow/ (2 places) (same) scsi/adapters/espvar.h (same) X11 (2 places) #de ne True 1 #de ne False 0 rp c/typ es.h #de ne FALSE (0) #de ne TRUE (1) sundev/dfreg.h #de ne TRUE 1 (but not FALSE!) sunwindow/sun.h typ edef enum fFalse = 0, True = 1g Bo ol; InterViews static const unsigned true = 1; static const unsigned false = 0; Rogue Wave Matrix (same as curses.h) C++Views (same as curses.h) sys/typ es.h (Solaris) B FALSE and B TRUE enumerators Table 2. Current de nitions of true and false. Wehave also found the following de nition of Bo olean in sys/typ es.h under Solaris 2.2: typedef enum boolean {B_FALSE, B_TRUE} boolean_t; with a reference to POSIX. It is however unclear if this de nition is part of POSIX or a Sun extension. Our conclusion is that the b o olean datatyp e is a fact of life whether it ++ is part of the C standard or not. However, there is currently a substantial variation in the de nitions, as shown by the tables. These variations create 3 X3J16/93-0143 WG21/N0350 several compatibility problems: Di erent names (e.g., bool, Bool, boolean, bool t) are used to identify one conceptual typ e. The Bo olean datatyp e may b e rede ned, which in the case of typ edefs is a fatal compilation error. Di erent de nitions may not b e typ e compatible, for example, Bo olean de ned as an int and as an enumeration. Overloading on Bo olean typ es is particularly sensitive. Di erent amounts of storage may b e allo cated for Bo olean typ es. ++ C has a less strict typ e system than C , so these variations are less of a ++ ++ problem in C than in C . Because C do es not allow implicit conversion from int to enumeration, current de nitions of Bo olean that use an enumer- ation cannot b e used without a large numb er of explicit typ ecasts. In the case of Solaris 2.2, this is particularly worrying b ecause a de nition in sys/typ es.h is likely to frequently used. Built-in vs. user-de ned typ e Adding a new typ e is essential for overloading. For example: void f(int); void f(bool); main() { f(3 < 4); } In order for this example to work, bool must b e a built-in or enumeration typ e; there is simply no way around it. On the other hand, allowing the standard promotion from bool to int is essential for backward compatibility: void f(int); void f(double); main() { f(3 < 4); } would change meaning otherwise. The p oint of the standard promotion is to p ermit any bool expression to act precisely likeanint expression in the absence of explicitly declared bool ob jects. The Bo olean datatyp e cannot b e de ned as an ordinary class typ e b ecause of the rule that says that at most one user-de ned conversion is automatically applied: class X { public: X(int); }; void f(X); main() { f(3 < 4); } For f(3<4) to work, the conversion from bool to int must not b e a user- de ned conversion. 4 X3J16/93-0143 WG21/N0350 Conversion from int to bool For similar reasons, conversion from numeric or p ointer typ es to bool must b e allowed. We do not exp ect p eople to stop using int values to hold ags, which means that things like int done = 0; while (!done) { // ... if (/* ... */) ++done; // ... } must remain legal. In this example, the expression !done causes done to b e converted to bool b efore negation, with exactly the same semantics as always.