GotW #26: Bool

GotW #26

On the
blog

November 4: Other Concurrency Sessions at PDC
November 3: PDC'09: Tutorial & Panel

October 26: Hoare on Testing
October 23: Deprecating export Considered for ISO C++0x

This is the original GotW problem and solution substantially as posted to Usenet. See the book Exceptional C++ (Addison-Wesley, 2000) for the most current solutions to GotW issues #1-30. The solutions in the book have been revised and expanded since their initial appearance in GotW. The book versions also incorporate corrections, new material, and conformance to the final ANSI/ISO C++ standard.

Bool
Difficulty: 7 / 10

Do we really need a builtin bool type? Why not just emulate it in the existing language? This GotW shows the answer.

Problem

Besides wchar_t (which was a typedef in C), bool is the only builtin type to be added to C++ since the ARM.[1] Could bool's effect have been duplicated without adding a builtin type? If yes, show an equivalent implementation. If no, show why possible implementations do not behave the same as the builtin bool.

Solution

The answer is: No. The bool builtin type (and the reserved keywords true and false) were added to C++ precisely because they couldn't be duplicated completely using the existing language.

If no, show why possible implementations do not behave the same as the builtin bool.

There are four major implementations:

Option 1: Typedef (score: 8.5 / 10)

This option means to "typedef <something> bool;", typically:

    typedef int bool;
    const bool true  = 1;
    const bool false = 0;

This solution isn't bad, but it doesn't allow overloading on bool. For example:

    // file f.h
    void f( int  ); // ok
    void f( bool ); // ok, redeclares the same function

    // file f.cpp
    void f( int  ) { /*...*/ }   // ok
    void f( bool ) { /*...*/ }   // error, redefinition

Another problem is that it can allow code like this:

    void f( bool b ) {
        assert( b != true && b != false );
    }

So Option 1 isn't good enough.

Option 2: #define (score: 0 / 10)

This option means to "#define bool <something>", typically:

    #define bool  int
    #define true  1
    #define false 0

This is, of course, purely evil. It not only has all of the same problems as Option 1 above, but it also wreaks the usual havoc of #defines. For example, pity the poor customer who tries to use this library and already has a variable named 'false'; now this definitely behaves differently from a builtin type.

Trying to use the preprocessor to simulate a type is just a bad idea.

Option 3: Enum (score: 9 / 10)

This option means to make an "enum bool", typically:

    enum bool { false, true };

This is somewhat better than Option 1, in my opinion. It allows overloading (the main problem with #1), but doesn't allow automatic conversions from a conditional expression (which would have been possible with #1), to wit:

    bool b;
    b = ( i == j );

This doesn't work because ints cannot be implicitly converted to enums.

Option 4: Class (score: 9 / 10)

Heck, this is an object-oriented language, right? So why not write an class, typically:

    class bool {
    public:
        bool();

        bool( int );      // to enable conversions from
        operator=( int ); //  conditional expressions

        //operator int();   // questionable!
        //operator void*(); // questionable!

    private:
        unsigned char b_;
    };

    const bool true ( 1 );
    const bool false( 0 );

This works except for the conversion operators marked "questionable". They're questionable because:

1. WITH an automatic conversion, bools will interfere with overload resolution, just as do all classes having non-explicit (conversion) constructors and/or automatic conversions (especially conversions from/to common types).

2. WITHOUT a conversion to something like int or void*, bool objects can't be tested "naturally" in conditions. For example:

    bool b;
    /*...*/
    if( b ) // error without an automatic conversion to
    {       // something like int or void*
        /*...*/
    }

It's a classic Catch-22 situation: We must choose one or the other, but neither option lets us duplicate the effect of having a builtin bool type.

Summary

A typedef ... bool wouldn't allow overloading on bool.

A #define bool wouldn't allow overloading either and would wreak the usual havoc of #defines.

An enum bool would allow overloading but couldn't be automatically converted from a conditional expression (as in "b = (i == j);").

A class bool would allow overloading but wouldn't let a bool object be tested in conditions (as in "if( b )") unless it provided an automatic conversion to something like int or void*, which would wreak the usual havoc of automatic conversions.

Yes, we really did need a builtin bool! And, finally, there's one more thing (related to overloading) that we couldn't have done otherwise, either, except perhaps with Option 4: specify that conditional expressions have type bool.

Notes

1. M. Ellis M and B. Stroustrup. The Annotated C++ Reference Manual (Addison-Wesley, 1990).

BoolDifficulty: 7 / 10