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).