|
On Jul 1, 2013 7:20 PM, "Sean Conner" <sean@conman.org> wrote:
>
> It was thus said that the Great Tim Hill once stated:
> >
> > Think about booleans in C; they don't exist as a 1st class type, but they
> > DO have an agreed-upon standard representation (that compilers
> > understand). If we didn't have that, every project would define it's own
> > arbitrary true and false, and each project, by itself, would work fine.
> > But then each 3rd party library you use would have a different standard,
> > and you would have to have conversion logic to transition between their
> > arbitrary boolean and yours; for each and every library. Urgh!
>
> Actually, I've seen plenty of C code improperly define the value for true.
> In C, a value of 0 is considered false, and *anything but 0* is considered
> true, so (in my not so humble opinion) the best definition of TRUE and FALSE
> would be:
>
> #define FALSE 0
> #define TRUE !FALSE
>
> But I've seen code that does:
>
> #define TRUE 1
> #define FALSE 0
>
> which mostly works, but can fail in some obscure cases.
>
> C99 solves that issue with _Bool (or bool, if you include <stdbool.h>) and
> constants for true and false, so maybe there is something to this.
>
> -spc
>
>
Some C compilers are so confident in their assumption that true=1, false=0 that other values can be both true and false at the same time: http://markshroyer.com/2012/06/c-both-true-and-false