#include <stdbool.h>

The header stdbool.h in the C Standard Library for the C
programming language contains four macros for a Boolean data
type. This header was introduced in C99, which was adopted as
an ANSI standard in May 2000. 11 years ago.


#ifndef _STDBOOL_H
#define _STDBOOL_H

#define bool _Bool
#define true 1
#define false 0
#define __bool_true_false_are_defined 1

#endif

Spread the word!

yeah okay, so what's _Bool supposed to be

C99 is still not fully supported. i will stick with C98 thank you

how bool is better than int?

>>2
Built-in compiler defined type. Identifier names with an underscore as a prefix are reserved as for future language expansions and compiler and library implementors. However, bool was not a reserved identifier in C89.

stdbool.h was created so that C99, and future versions of C such as C1x would remain backwards compatible with C89 code. For example, many C developers would create their own bool typedefs. On new projects, you can optional include stdbool.h. On existing projects, things work as per normal.

>>3
C99 is mostly full supported, except with Microsoft's shitty compiler toolchain.

>>4
Better semantics and type-safety. Plus bool can be implemented as a single byte (with ICC, GCC and Clang you choose this with a compiler flag), but int has to be at least 16-bits according to the language standard, as the minimum allowed values for INT_MAX and UINT_MAX in limits.h are 32767 and 65535 respectively. In practice with modern compilers and on most current platforms, int is a 32-bit integer type--but you already knew that.

>>4

sizeof(_Bool)

>>5

Out of curiosity, I always wondered why people didn't use char instead of int for representing booleans in pre-C99 code.

bool can be implemented as a single byte
How is that supposed to work?

>>5,7
Interestingly, the spec doesn't place an upper bound on the size of _Bool; the size must be enough to hold 1 or [/code]0[/code].

>>9

It wouldn't make sense to put an upper bound on sizeof(_Bool), because that could give a performance penalty due to alignment issues. Thus, there's no relative performance bonuses of using _Bool instead of anything else for that purpose; instead, I suppose the only advantage of _Bool is a little more explicit semantics associated with the type.

>>10
TBH the main reason I use bool in my code is so the filthy VC-using republicans will get an error when they try to compile it.

>>11

I lol'd cuz that has happened to me.

>>11
Agreed. I used to rely on stdint.h for this purpose, but VC10 finally got stdint.h so now we need to use more esoteric things like stdbool.h and tgmath.h.

>>7
Probably because they're faster to use, and losing 1-3 bytes of memory isn't exactly a huge loss.

>>8
1 = true
0 = false
>>7
I do.

Coming from an asm background, I don't see much need for bool as I'd extend my functions to return more than true/false (e.g. instead of returning true/1 for error, return a non-zero error reason.)

>>5
type-safety.
Only faggots care about typesafety. Because typesafe languages always miss `eval` function, they have no ability for reproduction, meaning they are faggots of programming languages. So, if your language doesnt have `eval`, you are a fag.

Hey fags, what is the type of (eval (read))? Is it "typesafe"?

If your code uses Bool its defective Sepples shit.
You don't need any "Boolshit" in any program. Bitfields with 1bit storage already provide all you need for flags and boolean switches. An int can have 32 1-bit bitfields which would takes 32 to 128 bytes as Bools in C++.

>>15
What i was really wondering was if using _bool has any performance advantages over checking a char for non-0 value.

>>17
Its a cons.

>>20
wrong

>>19
 you can write bitmasks to check the entire int at once,
While you check 32 bools each time separately, i would check many ints(even more with SSE,POPCNT and clever bithacking)
And it would be easy to toggle them at once:
http://graphics.stanford.edu/~seander/bithacks.html#ConditionalSetOrClearBitsWithoutBranching

>>19
I don't think the standard mentions anything about that, a specific compiler might be clever about it however. But as far as I know optimization isn't quite there yet.

#define false 0
#define true !false

>>28
Sir, you are a genius.