Programming Forums > Application Development > C

nnxion · Oct 6th, 2005, 7:31 AM

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:

(Toggle Plain Text)

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

(Toggle Plain Text)

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

grumpy · Oct 6th, 2005, 7:46 AM

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.

Narue · Oct 6th, 2005, 7:47 AM

>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:

(Toggle Plain Text)

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:

(Toggle Plain Text)

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.

DaWei · Oct 6th, 2005, 7:48 AM

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.

bl00dninja · Oct 7th, 2005, 2:14 AM

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

Narue · Oct 7th, 2005, 7:35 AM

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

jim mcnamara · Oct 7th, 2005, 8:39 AM

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.

Oct 6th, 2005, 7:47 AM	#3
Narue Professional Programmer Join Date: Sep 2005 Posts: 419 Rep Power: 3	>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: (Toggle Plain Text) if ( done ) /* Equivalent to if ( done != 0 ) if ( !done ) /* Equivalent to if ( done == 0 ) 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: (Toggle Plain Text) typedef enum { jsw_false, jsw_true } jsw_bool; 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. __________________ Even if the voices aren't real, they have some pretty good ideas.

Oct 6th, 2005, 7:48 AM	#4
DaWei Resident Grouch Join Date: Jun 2005 Posts: 6,453 Rep Power: 10	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. __________________ Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code. Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

Oct 7th, 2005, 2:14 AM	#5
bl00dninja Programming Guru Join Date: Oct 2004 Location: namespace std Posts: 1,246 Rep Power: 5	i remember "inventing" this idea a while back. i thought i was so damn clever. then i saw it was common practice in C. __________________ i put on my robe and wizard hat... Have you ever heard of Plato, Aristotle, Socrates?...Morons.

Oct 7th, 2005, 7:35 AM	#6
Narue Professional Programmer Join Date: Sep 2005 Posts: 419 Rep Power: 3	>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. __________________ Even if the voices aren't real, they have some pretty good ideas.

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Oct 6th, 2005, 7:46 AM	#2
grumpy Programming Guru Join Date: Jun 2005 Location: Adelaide, South Australia Posts: 1,198 Rep Power: 5	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.

Oct 7th, 2005, 8:39 AM	#7
jim mcnamara Hobbyist Programmer Join Date: Jun 2005 Location: New Mexico Posts: 228 Rep Power: 4	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.

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)

Programming Forums > Application Development > C

Defining a bool type