Why are so many C programmers allergic to booleans and keep using ints instead?

I've never even used boolean wtf

#include

I don't like this because it muddies the water of what true is in C

When you use int you can basically easily have multiple booleans in one int by OR-ing and masking individual bits and defining macros for them.
return LOREM | IPSUM;

Can't really do that with booleans.

>RAM
Bools are basically ints that are equal to 111... or 000...

#define true 1

if (4 == true) { /* hmm... */
}

Attached: legeh.gif (200x200, 14K)

this is the most retarded post

It shows the flaw in using simple defines for boolean logic in C.

python
Python 3.6.6 (default, Jun 27 2018, 13:11:40)
[GCC 8.1.1 20180531] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 4 == True
False

What are you trying to say? Python is not C.

How about
if (4) { //really makes you think
}

how so? the general rule in C is that anything that's not 0 equals true. you break this rule when you introduce those defines.
if (4) {} /* evaluated as true */
if (4 == true) {} /* evaluated as false */

because it's not a part of the language (c89 is the only true C standard).

there are some conventions everybody uses.

1- if it returns a pointer, returns NULL on error
2- if it's a function that "does" something it returns 0 on success and anything other than 0 on failure.
3- if it checks something (usually starts with is_) it returns 0 on fail and anything other than 0 on success.

the impoelrtant line is #define bool _Bool, _Bool has a different behavior than integers and is compiler-implemented
will explore generated assembly later out of curiosity, it offers different type conversion rules e.g. for floats, protects from overflows as it's alway either 1 or 0 and just generally using bool keyword is cleaner to understand

>if (4 == true) {} /* evaluated as false */
every language works this way.

c99 is much better than c89
get your head out of your ass, boomer

??????????????????????

i don't care that other languages implement a bastardization of boolean logic. if statement A equals true then "A == true" must also be true.
it doesn't work with those defines so don't use them.

>2- if it's a function that "does" something it returns 0 on success and anything other than 0 on failure.
This is kinda stupid.
if (func(&sideeffect1, &sideeffect2)) {
...
} looks much cleaner than a check for 0

That doesn't make any sense since when you run if(2) do_something; "(2)" is actually returning 1, but 2 and 1 are not equal.

Attached: 9d5.png (2688x2688, 173K)

How about C++ ?

i believe it's because SUCCESS is only one thing but FAILURE has different forms, so being able to return different error codes for different failures is the main point.

It's not so fun to have to include loads of extra stuff. It's enough hassle already typing "#include " and all that. And ints work fine anyway

>you can't do non-boolean things with a boolean

>False
You mean 0

That makes sense so you could make a switch statement out of the result of a function.

>c89 is the only true C standard
Only retards who don't know C99+ say this. Good C programmers can easily switch between both and prefer C99/C11 where it's available.

How big is an m-n array C89-user?
m * n * sizeof (int)

How big is an m-n array C99-user?
sizeof (int[m][n])

How can I initialize this allocated struct C89-user?
strc->mem1 = 1;
strc->mem2 = 2;
strc->mem3 = NULL;
strc->mem4 = NULL;

How can I do this same initialization C99-user?
*strc = (struct T){.mem1 = 1, .mem2 = 2};

Biggest argument I can hear against it is variable length arrays. If you don't want them don't use them.

could also use errno for that

C supports bitfield syntax

Junk additions desu

For example:
unsigned char b1 = 256;
bool b2 = 256;

b1 becomes 0 (with a warning but the point is for when this is assigned at runtime), and b2 becomes 1 because the input is non-zero. The common workaround for non-bool booleans is:

b1 = !!x;
b2 = x; // no workaround needed

Is this a useful feature? Well it makes this particular bug less likely, not everyone remembers to use !!.

First correct answer in a thread full of C wannabes. Not even a single (you) until now

Basically all you're saying is that you don't know C

They're additions and they let me write shorter, cleaner code. For example I'm returning a union from a function:

C89:
PtrOrInt get_thing(void)
{
PtrOrInt result;
// . . .
result.ptr = val;
return result;
}

C99:
PtrOrInt get_thing(void)
{
// . . .
return (PtrOrInt){.ptr = val};
}

>Bools are basically ints that are equal to 111... or 000...
Why woul they do this

Attached: realshit.png (315x289, 191K)

They didn't do this

I would do it this way. I think it is cleaner.
int get_thing(union ptrint *out)
{
if (...) {
out->val = myval;
return 1;
}

out->ptr = myptr;
return 0;
}

This. Kiddos dont understand the atomicity of memory transactions in modern x86 these days. Sure, there may be a platform you can code up some C against for bit-wise memory allocations, but its not going to be one anyone gives a shit about.

So does the compiler lump multiple bools and shorts in one address for efficiency's sake?

Attached: efc.jpg (480x362, 39K)

Your best bet is to use bytes and store 8 boolean values per if you just want the most efficient way to store a shitload of boolean values. If you need to store an absolute metric fuckton of boolean values (e.g. bitmap indexes for databases), and are willing to make some tradeoffs in write performance, see: bitmap compression - EWAH is a good approach and actually increases read performance over baseline.

No you wouldn't, that's different code and I would use the same code in the right situation. It's missing the point to bring up different situations when you are presented with a good example of the strength of another language.

No, this isn't allowed unless you use bitfields, and it occurs in C++ when you do std::vector bizarrely (which breaks a lot of assumptions about std::vector, most people find themselves using std::vector or similar instead).

it's 1 byte anyway, you need to use masks if you want something more compact
C++ std::vector optimizes it to use 1 bit per bool

Because a bool is just an int under the hood.

it's not, read the specs

If you want this to happen, you will need to explicitly define a struct such that your boolean values are defined contiguously and have it aligned with word boundaries. Many game developers had to do shit like this (still do in many cases) to pack very complex data structures into the smallest amount of memory possible.

Further reading:
>catb.org/esr/structure-packing/

The feature for doing bit flags in C/C++ is bitfields (and std::vector).

Otherwise most people use bitwise or etc explicitly because then they define the actual values used and ABIs/IO becomes more stable.

this is because the 'true' gets casted to int and not the other way. bool has lowest priority

It's because the true define is just 1 on its own, this would actually satisfy a conditional:
4 == (bool)true

Who the fuck even uses plain ol C anymore lmao

warning: comparison of constant '4' with boolean expression is always false [-Wbool-compare]

please, tell me more

Let's just remove all the C programs from your computer

If statements compile down to jump-if-zero / jump-if-not-zero anyway.

Is this what passes for a CS education nowadays?

I'm writing an NES emulator in C.

All programs you write use C under the hood. It's the lingua franca of computation on the bare metal

OP seems to be asking specifically about programs written in C from the beginning though.

the overwhelming majority of embedded engineers

Linux

anyone with a functioning brain.

Everyone who isn't an open-space slave.
t. Closed office slave

Attached: doc.png (734x524, 481K)

They weren't included in ANSI C.

You guys have no idea what you are talking about. A bool is not 1 bit.

Its actually the word size. No benefit in a single byte.

$ python
Python 3.6.5 (default, Jun 8 2018, 01:39:02)
[GCC 4.2.1 Compatible Android (4691093 based on r316199) Clang 6.0.2 (a on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> bool(4)
True

really makes you think huh

>a bool is a bit

>Bools are basically ints that are equal to 111... or 000...

Attached: 1529475557278.jpg (320x191, 8K)

Why have 2 possible return values when you can have 256 possible return values for the same memory usage?

Attached: 1527928443408.png (1200x1200, 1.22M)

Anyone that wants a library that can be used from many languages easily, for example sqlite. Anyone that wants a library that can be used on computers, phones and other devices - iOS doesn't allow your jitted languages to run on it.

It's more logical and cleaner to use bools boolean expressions. It's self documentation.

Why do pythonlets always have to open the console to show off python.
$ pyc 'bool(4)'
True

$ pyc 4 == True
False

There is absolutely no point in the boolean type when everyone knows 1 as true and 0 as false, bool is simply a restriction created in an effort to make code slightly closer to English but with no advantages to development

Cfags don't need a bool type when their language doesn't have the ability to overload functions on the parameter types.
Cfags don't need any types at all, and probably shouldn't have any types at all.
After all, types just make code slightly closer to English but with no advantages to development, right?
Fucking bloat.

>Cfags don't need a bool type when their language doesn't have the ability to overload functions on the parameter types
What? C doesn't have the paradigms built in; however, you can accomplish them with the use of macros.

Yes there is you fucking nigger

Do you have to do anything special to deal with your autism?

It's the same guy you fuckin' idiot.

What proof do you have for that? Anyway, that wasn't the point; reading and comprehension isn't your strong suit, is it?

bools weren't in C89. People still write C89 for portability reasons.

except that half of the time when 0 is no error and non-0 is error

it is built in, _Bool behavior is defined in compiler, not any library

For reasons of speed, booleans are implemented as ints. So it is easier to just use ints to begin with.

You don't have to dumb shit down like that for C programmers.

Attached: 1532025613291.gif (1000x640, 127K)

>love C, learned through king's modern approach
>try picking up bjarne's C++ tome
>C++ is hideous and I despise it

is this normal

No. They're implementation defined and you are full of shit.

Yes, C is beautiful.
C++ is a disgusting hack.

C++ is all about choosing which parts of the language you're going to use. You are going to hate most of it and end up with C and a few neat tools if you do it right. The downside is you might
need to understand some extra stuff to use code others write.

Attached: 143.jpg (599x282, 15K)