3 ms·

> While 'bool' is valid C99 code, it is more or less never used in C code. I disagree. It's used quite a bit in the code I work on. Little things like an expli

by rcfox 14y ago

> While 'bool' is valid C99 code, it is more or less never used in C code. I disagree. It's used quite a bit in the code I work on. Little things like an explicit statement that this variable is only true or false significantly reduce the cognitive load when reading code. Anyway, even if it were true that nobody uses bool, there's absolutely no reason to discourage its use.

zvrba 14y ago
> Little things like an explicit statement that this variable is only true or false significantly reduce the cognitive load when reading code. Since it's allowed to use bool in arithmetic context (some_int + some_bool will compile fine, for example), having a bool type is useless. (Useless in C and C++ that is; Java, for example, has sane bool handling.) I have no idea why C99 introduced _Bool type when they could have just inserted typedef char bool; in stdbool.h. Has anybody ever used for something useful the fact that memory representation of _Bool is constrained to read as 0 or 1?
- VMG 14y ago
  it still is a useful annotation
- fusiongyro 14y ago
  1. It's semantically valuable, or you wouldn't see it defined in everyone's code 2. C lets you commit all kinds of atrocities in arithmetic contexts with or without it. 3. Having a standard typedef saves us from all having to make our own 4. None of your points support the case of "don't use stdbool"
  - zvrba 14y ago
    > 4. None of your points support the case of "don't use stdbool" Huh? I was saying that the language did not have to be extended to get a bool typedef. C99 defines a new type, _Bool (name from the reserved identifier space), which is different from existing types. stdbool is a simple typedef of _Bool to bool. Also, introducing bool would have had meaning if implicit conversion to int wasn't allowed. But since it is, it's a useless type. My viewpoint is that types exist for enforcing semantic constraints; what use of a bool type that allows performing semantically nonsense operation, such as implicit conversion to int in arithmetic context? The C99 committee messed it up big with bool.
    - fusiongyro 14y ago
      Adding it to the language saves us all the work of typedefing it. Which is a very common practice. C's approach to typing is, in general, pretty weak. Mostly they're there so the compiler can decide how much space to set aside. There's no point singling out this particular instance of nonsense when everywhere you turn in C you're greeted by other forms of the same nonsense. There's no point being pedantic about bool if you're not going to be pedantic about all the other types. Enough bikeshedding. Use it or don't.
      - zvrba 14y ago
        > There's no point singling out this particular instance of nonsense when everywhere you turn in C you're greeted by other forms of the same nonsense. By your reasoning, since nonsense already exists, it's pointless to try to do the right thing. And they could have done it.
- alexchamberlain 14y ago
  Presumably some optimiser could use this fact to pack several bools into the same register?

by rcfox 14y ago

zvrba 14y ago

> Little things like an explicit statement that this variable is only true or false significantly reduce the cognitive load when reading code. Since it's allowed to use bool in arithmetic context (some_int + some_bool will compile fine, for example), having a bool type is useless. (Useless in C and C++ that is; Java, for example, has sane bool handling.) I have no idea why C99 introduced _Bool type when they could have just inserted typedef char bool; in stdbool.h. Has anybody ever used for something useful the fact that memory representation of _Bool is constrained to read as 0 or 1?

VMG 14y ago
it still is a useful annotation
fusiongyro 14y ago
1. It's semantically valuable, or you wouldn't see it defined in everyone's code 2. C lets you commit all kinds of atrocities in arithmetic contexts with or without it. 3. Having a standard typedef saves us from all having to make our own 4. None of your points support the case of "don't use stdbool"
- zvrba 14y ago
  > 4. None of your points support the case of "don't use stdbool" Huh? I was saying that the language did not have to be extended to get a bool typedef. C99 defines a new type, _Bool (name from the reserved identifier space), which is different from existing types. stdbool is a simple typedef of _Bool to bool. Also, introducing bool would have had meaning if implicit conversion to int wasn't allowed. But since it is, it's a useless type. My viewpoint is that types exist for enforcing semantic constraints; what use of a bool type that allows performing semantically nonsense operation, such as implicit conversion to int in arithmetic context? The C99 committee messed it up big with bool.
  - fusiongyro 14y ago
    Adding it to the language saves us all the work of typedefing it. Which is a very common practice. C's approach to typing is, in general, pretty weak. Mostly they're there so the compiler can decide how much space to set aside. There's no point singling out this particular instance of nonsense when everywhere you turn in C you're greeted by other forms of the same nonsense. There's no point being pedantic about bool if you're not going to be pedantic about all the other types. Enough bikeshedding. Use it or don't.
    - zvrba 14y ago
      > There's no point singling out this particular instance of nonsense when everywhere you turn in C you're greeted by other forms of the same nonsense. By your reasoning, since nonsense already exists, it's pointless to try to do the right thing. And they could have done it.
alexchamberlain 14y ago
Presumably some optimiser could use this fact to pack several bools into the same register?