Re: Absense of bool

"J. J. Farrell" <jjf@xxxxxxxxxx> writes:
On Nov 4, 4:09 pm, Richard <rgr...@xxxxxxxxx> wrote:
[...]
Lets turn it around. Why would you think having a real boolean is NOT a
good idea?

I don't think that, and never suggested that I did. I don't have any
strong feelings on the subject at all. I'm not sure that I consider
it's absence a flaw, but if it is it's a very minor one. I wouldn't
object to its presence; its usefulness might outweigh the complexity
it would add, but by very little. Overall it doesn't much matter
either way in my opinion.

The only real utility I can see in it is self-documentation of code,
but that's easily achieved by a programmer-defined typedef or even by
the name of the variable. It doesn't seem to warrant a fundamental
type.

The trouble is that there are a gazillion subtly different
programmer-defined typedef. I might use
typedef enum { false, true } bool;
and you might use
typedef int bool;
#define false 0
#define true 1
and anyone trying to mix my code with yours has to resolve the
incompatible declarations. The name collision problem can be (mostly)
avoided with unique prefixes:
typedef enum { kst_false, kst_true } kst_bool;
typedef int jjf_bool;
#define jjf_false 0
#define jjf_true 1
but that's ugly.

The point of defining it once and for all in the language isn't that
defining it yourself is too hard; it's that it's easy enough that
everyone does it incompatibly.

C99 *could* have used a simple typedef and a couple of macros in
<stdbool.h>:
typedef int bool; /* or perhaps "typedef intfast8_t bool;" */
#define false 0
#define true 1
but to get the desired behavior of converting any scalar value to bool
and getting either 0 or 1 (false or true), it was necessary to create
a new fundamental type _Bool.

I'm just puzzled why someone should see its absence as a MAJOR flaw,
to the extent that they can't conceive that the need for it didn't
occur to the inventors of the language. That's why I was asking.

I agree that the lack of a boolean type it's not a major flaw, but I'm
glad C99 added it.

If I were designing C from scratch today, I'd probably make bool a
built-in type from the beginning, make the relational and equality
operators yield bool results, and require bool expressions for
conditions. (I personally wouldn't provide implicit conversions to
bool; others would want that.)

--
Keith Thompson (The_Other_Keith) kst-u@xxxxxxx <http://www.ghoti.net/~kst>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
.

Relevant Pages

  • Re: short circuit evaluation
    ... typedef because it makes more sense to me that it would be a ... Does anyone know why it's a macro? ... making 'bool' a macro allows you do so. ... I wasn't asking about why C99 didn't make bool a reserved word. ...
    (comp.lang.c)
  • Re: short circuit evaluation
    ... typedef because it makes more sense to me that it would be a ... Does anyone know why it's a macro? ... making 'bool' a macro allows you do so. ... Because 'bool' was not a reserved word in C90. ...
    (comp.lang.c)
  • Re: About -lm switch used for linking math.h
    ... but that is a typedef to "_Bool" that one gets by ... not a typedef. ... Because it expands to a C language keyword, ... pack of three might as well be macros. ...
    (comp.lang.c)
  • Re: short circuit evaluation
    ... typedef because it makes more sense to me that it would be a ... Does anyone know why it's a macro? ... making 'bool' a macro allows you do so. ... Because 'bool' was not a reserved word in C90. ...
    (comp.lang.c)
  • Re: [RFC][PATCH] A generic boolean (version 3)
    ... Define a Boolean data type. ... +typedef bool boolean; ... +#undef false ...
    (Linux-Kernel)