Programming Forums - Defining a bool type

Programming Forums (http://www.programmingforums.org/forumindex.php)

- C (http://www.programmingforums.org/forum60.html)

- - Defining a bool type (http://www.programmingforums.org/showthread.php?t=6286)

Defining a bool type

In another thread I saw someone included genlib.h, so looked it up and saw the following:

/*

 * Type: bool

 * ----------

 * This type has two values, FALSE and TRUE, which are equal to 0

 * and 1, respectively.  Most of the advantage of defining this type

 * comes from readability because it allows the programmer to

 * provide documentation that a variable will take on only one of

 * these two values.  Designing a portable representation, however,

 * is surprisingly hard, because many libraries and some compilers

 * define these names.  The definitions are usually compatible but

 * may still be flagged as errors.

 */



#ifdef THINK_C

   typedef int bool;

#else

#  ifdef TRUE

#    ifndef bool

#      define bool int

#    endif

#  else

#    ifdef bool

#      define FALSE 0

#      define TRUE 1

#    else

       typedef enum {FALSE, TRUE} bool;

#    endif

#  endif

#endif

Would the above be more portable than what I have in some of my own code:

#ifndef __cplusplus

#undef false

#undef true

#undef bool

#define false 0

#define true !false

typedef int bool;

#endif

Or would this be even better:

Quote:

Originally Posted by K&R2

Nevertheless, enumeration variables offer the chance of checking and so are often better than #defines. In addition, a debugger may be able to print values of enumeration variables in their symbolic form.

#ifndef __cplusplus

#undef false

#undef true

#undef bool

enum bool{ false, true = !false };

#endif

I could also define false like: #define false ('\0')

I am not sure why that would be better though.

I am using true != false, since true doesn't always have to be 1, but just not false. I do not care about other third-party libraries, so I just #undef them if they exist. I am also presuming that one only uses either C or C++, not another programming language like Objective C (of which I do not know if it has the bool type).

The issues with booleans (defining the acceptable values, defining the name of the type, etc) are one of the reasons that C++ supports the bool type and true/false keywords.

In the examples above I would not bother with "#define true !false" or "enum bool {false, true};". Simpler forms that achieve exactly the same things are "#define true 1" and "enum bool {false, true};" respectively.

The main problems with such techniques come in if you're reusing other people's code. There are many possible variants of this sort of scheme: using such techniques, no matter what you do, you will encounter some code that breaks because of mixing and matching two techniques.

>Would the above be more portable than what I have in some of my own code
Not necessarily. You're assuming that true, false, and bool are all #define's.

>enum bool{ false, true = !false };
There's no need to set the value for true, it'll be 1 since an unset starting value for enumerations is 0 and it increments by one for each constant defined. You'll also be forced to say "enum bool" whenever you want to use the type. A typedef is required to remove that if you want to use enumerations.

>I am using true != false, since true doesn't always have to be 1, but just not false.
It doesn't have to be 1 (with false being 0), but it sure does make your life easier when you follow that convention. Why? Because C has a tendency to assume it, such as when you use a boolean test:

if ( done ) /* Equivalent to if ( done != 0 )

if ( !done ) /* Equivalent to if ( done == 0 )

You'd really be better off forgetting about trying to make it portable across unknown libraries. Simply make it portable across the libraries you use, or add your own naming convention and avoid the issue entirely:

typedef enum { jsw_false, jsw_true } jsw_bool;

Alternatively, start using C99 and you can take advantage of the _Bool type, and optionally include stdbool.h if you want the bool, true, and false helpers and it doesn't cause conflicts.

I think it's pretty much a personal, stylistic, issue so long as it works for you, and doesn't break anything. The fact is that, for a true boolean, a logical not and a bitwise not would result in the same thing. You don't have the degree of control necessary to force that behavior onto an integer.

i remember "inventing" this idea a while back. i thought i was so damn clever. then i saw it was common practice in C.

>then i saw it was common practice in C.
That's because the idea is so damn clever. :p Good ideas have a tendency to be discovered independently by a bunch of people. Just because an idea already exists doesn't diminish the accomplishment of you inventing it independently.

Speaking of conflicts.

I work with a gigantic proprietary library. Keeping the vendor's name out of it - there are lots of conflicts with standard C and unix system calls. For example, some idiot created a round() function. If you want to use the round() in libm then you have to play games. I wrote re-wrote round as "PNMround()", so now we use that. PNM is a company name. This is NOT needful, you should never create situation like this.

The same thing applies here with true and false. You simply need to be internally consistent with your libraries and the standard C library. You don't want the next guy - and there always is a next guy - to go nuts trying to work around conflicts that do not need to be there in the first place.