On Sun, Sep 14, 2014 at 03:26:15PM +0100, Thomas Adam wrote:
> On Sat, Sep 13, 2014 at 01:28:34PM +0100, Dominik Vogt wrote:
> > Argh! In X, the constant "True" is defined to 0, so freeing the
> > repeat string was done when it shouldn't be and vice versa. One
> > day I'll clean up that crap with True vs. TRUE vs. !!x vs. x == 1.
>
> Why do we have it? I mean, I can understand not wanting to use the C99
> type of 'bool' but nowadays 'bool' might be OK, and even if you're
> paranoid about older compilers and standards, why not just use an
> integer for everything?
I can't remember. Once we had mostly ints with a few scattered
occurances of the constants TRUE and FALSE defined inside fvwm.
Then there must have been a time where I thought using a single
type was a good thing, to I started using Bool. Nowadays I'd like
to go back to plain C truth values stored in any integer type, i.e.
"!foo" means false and "foo" means true.
> The problem with using "True" or "False" is
> that you have to remember to actually use them and compare against them.
Yes. I just double checked with Xlib.h, and True is defined to 1,
so I don't know why it failed. However, Xlib uses Bool as a type,
so it cannot be completely eliminated.
> There's still cases in fvwm where:
>
> Bool do_something(void)
> {
> fprintf(stderr, "You what?");
>
> return True;
> }
>
> if (do_something() == 1) { ... }
>
> Happens, and that to me speaks volumes about the usefulness of declaring
> True/False over just having an int or using a 'bool' type.
For me, the right approach is to always use int (or any other C
integer type), and *never* compare it to a literal value.
is_foo = 0; /* false */
is_foo = 1; /* true */
is_foo = -1; /* also true */
if (!is_foo) /* is false */;
if (is_foo) /* is true */;
This also works with bit fields in structs, whereas
if (is_foo == 1)
works only with "insigned int : 1", and
if (is_foo == -1)
works only with "signed int : 1".
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
