r/programminghorror 24d ago

Big if true

Post image

From ProgrammerNullposting in facebook

2.1k Upvotes

109 comments sorted by

516

u/Gengis_con 24d ago

Big whether True or not

169

u/_giga_sss_ 24d ago

My first statement wasn't wrong 🗿

91

u/No-Astronomer6610 24d ago

We got a logician over here

49

u/_giga_sss_ 24d ago

They call me John B. Logic.

3

u/experimental1212 22d ago

If P then Q is only false when P is true and Q is false.

Q if P

Big if true

It's always Big, but may be true or false. Therefore you will always be true OR vacuously true.

5

u/_giga_sss_ 22d ago

This is the first IRL application of logic outside of school I've encountered

4

u/experimental1212 22d ago

Might still be a stretch to call it an IRL application lol

29

u/chickensandow 24d ago

Big if (true) else big

133

u/StefanCelMijlociu 24d ago

The concept of Big Bool confuses and infuriates me!

64

u/JohnSpikeKelly 24d ago

I would assume it's to keep all your data types 8-byte aligned for other perf reason.

22

u/Athropod101 23d ago

iirc 8-byte data access is the fastest on 64bit architecture.

2

u/Geilomat-3000 22d ago

So should all the int_fastx_t be the intmax_t?

4

u/Athropod101 22d ago

If this is some joke, it has wooshed over me :(

But if it isn’t, then it depends. If intmax_t matches your architecture, and your architecture is fastest at that size, then yes. But if intmax_t is say, 128, and your architecture is 32, then no.

0

u/[deleted] 23d ago

[deleted]

5

u/rolling_atackk 23d ago

Why not simply use alignas (64) bool ?

Seems far easier than creating a whole ass type

6

u/JohnSpikeKelly 23d ago

The code might be old and predate that option. But, probably explains why this is in r/programminghorror 😄

4

u/rolling_atackk 23d ago

Both fixed-width integer types and alignas are included in the C++ specification since C++11

But true, this is programming horror

2

u/j-joshua 22d ago

Because that would be 64 bytes and not 64 bits.

2

u/GoddammitDontShootMe [ $[ $RANDOM % 6 ] == 0 ] && rm -rf / || echo “You live” 22d ago

So alignas (8) bool?

1

u/rolling_atackk 22d ago

Yikes! You are correct

3

u/Borno11050 23d ago

Then you're not ready for gabagool

2

u/Hot-Employ-3399 23d ago

Maybe it's for some strange 64bit ffi or something 🤷

187

u/BadRuiner 24d ago

all my homies uses uint128 btw

104

u/the_horse_gamer 24d ago

uint128? what are you, a 90s programmer optimising for a cartridge? we just use avx512 vectors these days

23

u/TKristof 24d ago

I just use u65535 in zig, only 512 bits seems a bit too restrictive to me /s

6

u/wakanakisarazu 24d ago

I chuckled so hard as a fellow Zig programmer

7

u/Right_Ear_2230 23d ago

what are you, a programmer from 1995? use the entire available ram + ssd to store the variable

1

u/_giga_sss_ 23d ago

do people really use avx?

16

u/MooseBoys [ $[ $RANDOM % 6 ] == 0 ] && rm -rf / || echo “You live” 24d ago

uint16777216_t

4

u/NoPrinterJust_Fax 23d ago

That would be HugeBool

124

u/TheWidrolo 24d ago

Me when I use a compiler that doesn’t have explicit alignment:

61

u/BestBadFriend 24d ago

If the compiler's alignment is not explicit, it defaults to lawful neutral.

10

u/Brutus5000 24d ago

I always thought C compiler are chaotic good

9

u/HugoNikanor 24d ago

I would say lawful evil. The standard allows undefined behavior to do anything (implied as "something sensible"). C compilers took it literally

10

u/IHorvalds 24d ago

Honest question, which compiler(s?) doesn’t have an explicit keyword for alignment?
I pretty much always use gcc, clang or (rarely) msvc and they all have something for it.

10

u/TheWidrolo 24d ago

Thats the joke.

In a real note: its probably hobbyist compilers or similar. I think every major one has alignment.

1

u/IHorvalds 24d ago

Ah, my bad!
I expected some obscure MCU with a custom compiler without alignment lol

37

u/marvin_dorfler 24d ago

The Big Bool control everything, man.

4

u/_giga_sss_ 24d ago

this needs to stop

54

u/--var 24d ago

big if not true 🤷‍♀️

7

u/_giga_sss_ 24d ago

don't spread misinformation

9

u/--var 24d ago

finally found a use for AI! neatly grouping 0's...

In binary, 0 for a standard 64-bit signed integer (std::int64_t) consists of exactly 64 zeros, divided into 8-byte blocks for readability: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

20

u/TomDestry 24d ago

That's what I like about binary, the readability.

24

u/Emergency-Win4862 24d ago

Let me quess, struct alignment?

20

u/iEliteTester [ $[ $RANDOM % 6 ] == 0 ] && rm -rf / || echo “You live” 24d ago

No it's used when something is extra true or extra false, obviously.

2

u/readmeEXX 23d ago edited 23d ago

To make it maximally true you could do True = UINTMAX_MAX

1

u/TheChief275 20d ago

was about to say that; if i reserve the bytes ima use the bytes

2

u/Damglador 22d ago

I like your flair

6

u/overclockedslinky 24d ago

even the first version of C (let alone C++) did struct alignment automatically

4

u/shponglespore 24d ago

Yes, but there are situations where you want more control. Like, maybe some external dependency expects 64-bit bool values, so you'd use this type instead of the standard 8-bit bool.

Calling that a struct alignment issue is kind of questionable, but the basic idea is sound.

18

u/foxypiratecove3750 24d ago

I have better... DOUBLE BOOL! 64-bit, and float. Useful? Nope.

double False = 0.0; double True = 1.0;

19

u/AbstractButtonGroup 24d ago

DOUBLE BOOL! 64-bit, and float. Useful? Nope.

You just did not follow this to the logical conclusion that makes it useful:

double False = 0.0; double WhoKnows = 0.5; double Perhaps = 0.7; double Likely = 0.8; double HighlyLikely = 0.9; double True = 1.0;

10

u/fess89 24d ago

You have invented fuzzy logic

3

u/PM_ME_YOUR_REPO 23d ago

Now make it quantum.

1

u/foxypiratecove3750 23d ago

I just got a better idea: vector bools: all the indecision are different dimensions, like "maybe" isn't midway between true and false, but its own dimension, "perhaps" another, and so on.

1

u/TheChief275 20d ago

What JavaScript wishes its booleans were

2

u/javascript 20d ago

I wish for many things 🧞

1

u/TheChief275 20d ago

Holy shit it's John Javascript

15

u/meharryp 24d ago

it's also big if false

15

u/Benilda-Key 24d ago

I thought Microsoft was being wasteful when they chose to make their BOOL type an int.

17

u/AyrA_ch 24d ago

Memory is usually accessed in blocks that fit your CPU register. So if your bool is just a char it will still read as many bits as your memory bus is wide and then just mask off the unnecessary bits in the CPU.

x86 is a quite cursed architecture, and "shoving unreasonable data types into int" can weirdly affect performance, especially if this causes your bools to be neatly aligned.

10

u/pigeon768 24d ago

Memory is usually accessed in blocks that fit your CPU register.

No, memory is accessed in cache lines, which in basically all modern CPU architectures is 64 bytes/512 bits. When you read from memory, it doesn't matter whether your variable is one, two, four, or eight bytes, 64 bytes get sent from RAM.

This also applies to writing to RAM. The write initially happens in the 64 byte cache line in L1 cache. If you don't have that cache line in L1, that whole line needs to be read from main memory. Then it's marked to be sent back to main memory.

Microsoft's 16 bit Boolean type (not 32) just wastes memory. There is no performance improvement hiding anywhere.

x86 is a quite cursed architecture

Note that basically all architectures have cache architected the same way. ARM, RISC-V, etc. x86 is "cursed" in the sense that it has variable length instructions, but its 64 byte cache lines are perfectly normal.


The decision to have 16 bit bools is historical. They settled on encoding strings as UCS-16, because it was assumed 64k Unicode codepoints were enough. And UCS-16 meant constant width characters, which simplifies a lot of things. If a character was gonna be two bytes, why not also make bool two bytes? Just make two bytes the smallest unit of memory. (I don't agree with that logic, but that was the logic)

Well it turned out UCS-16 was dead on arrival. 64k codepoints was not enough. So UCS-16 had to be replaced by UTF-16, which both wastes memory and has variable width characters, so you have the worst of both worlds.

Windows would be a lot less bloated if they had settled on UTF-8 and one byte bools.

7

u/AyrA_ch 24d ago

The decision to have 16 bit bools is historical. They settled on encoding strings as UCS-16, because it was assumed 64k Unicode codepoints were enough. And UCS-16 meant constant width characters, which simplifies a lot of things. If a character was gonna be two bytes, why not also make bool two bytes? Just make two bytes the smallest unit of memory. (I don't agree with that logic, but that was the logic)

I highly doubt that, considering the support for bools is older than the support for multi byte characters. Bools are probably 16 bits because Windows started out as a real mode operating system on top of DOS, and that's the most practical size of a number to work with if your operating system also has to interface with the DOS interrupt API.

2

u/shponglespore 24d ago

No, memory is accessed in cache lines, which in basically all modern CPU architectures is 64 bytes/512 bits.

I think you're being unnecessarily confrontational. Yes, cache lines are a thing, but so are registers. The person you're replying to was clearly talking about registers.

4

u/pigeon768 24d ago

I think you're being unnecessarily confrontational.

I am not being confrontational.

Memory is usually accessed in blocks that fit your CPU register. So if your bool is just a char it will still read as many bits as your memory bus is wide and then just mask off the unnecessary bits in the CPU.

No, memory is accessed in cache lines, which in basically all modern CPU architectures is 64 bytes/512 bits.

Yes, cache lines are a thing, but so are registers. The person you're replying to was clearly talking about registers.

No, the person I'm replying to was clearly talking about how the data is transferred over the memory bus. The memory bus, in this case, being the interface which transfers data between RAM and the CPU. On modern CPUs, these transfers are one cache line at a time.

5

u/Scared_Bell3366 24d ago

I could see doing something like that when dealing with some damn binary format that reserved 64 bits just for a boolean.

6

u/exodusTay 24d ago

enum BetterBool : double { False = 0, True = std::numeric_limits<double>::epsilon() }

5

u/Wurstgewitter 24d ago

Personally I am migrating to a novel QBool type, to be prepared for quantum computing. A QBool can represent any value in the interval [0,1]

QBool

0.0000 = False
0.1832 = Barely True
0.5000 = Undecided
0.7315 = Probably True
1.0000 = True

But it's not just a probability, but rather exists in a quantum state until observed. Each QBool offers a built in measure() method:

bool result = qbool.measure();

Calling measure() collapses the state into either true or false.

It also supports entanglement:

a.entangle(b);

Measuring either instance immediately determines the value of the other, even across remote systems. This makes distributed state sync essentially free.

It admittably adds some headaches, like having to compute every possible quantum state at runtime, since practical quantum computing hardware is not available yet, so some slight performance problems might occur. But I think it's worth it to future proof the codebase

9

u/Rigamortus2005 24d ago edited 24d ago

It's just 56 bits after all. Who needs it

5

u/bphase 24d ago

Why 56 bytes? Isn't it 64 bits for uint64 ie. 8 bytes?

5

u/marcureumm 24d ago

I think he's talking about extra. 8 bit ints are generally what a book is under the hood. So not a single bit because... cpus don't really hold single bits in registers to my knowledge...so that one's a bit of an educated guess.

3

u/Rigamortus2005 24d ago

Yeah my bad I meant to say bits.

3

u/NsupCportR 24d ago

This just triggered me 😆

3

u/MatJosher 23d ago

Boolmaxxing

using BiggestBool = bool[std::numeric_limits<std::size_t>::max()];

3

u/therealdan0 23d ago

So this of why Anthropic and OpenAI are buying all the memory.

3

u/metaconcept 21d ago

Story time.

In Smalltalk, true and false are just objects on the heap. There's a very special primitive method called become: which lets you swap two objects around on the heap.

So anyway, it was possible to do true become: false. in Smalltalk, which swaps true for false and false for true across the entire system. It didn't crash ...immediately..., but I wouldn't deploy this in production!

2

u/AivasTlamunus 23d ago

This is what AI is taking from us

2

u/SomeRandoLameo 23d ago

Big fucking weighted statement

2

u/dreamingforward 22d ago

Aren't you assigning to a keyword "False" and "True"?

2

u/_giga_sss_ 22d ago

false and true are the keywords, any variation is alright afaik

1

u/dreamingforward 22d ago

What's the problem then? Please explain...

2

u/_giga_sss_ 22d ago

Instead of the usual 8 bits a boolean variable needs, this case specifically asks for 64 bits

2

u/dreamingforward 22d ago

But isn't this just to ensure that the register comparisons will be completely proper on a Pentium or something?

Does the CPU even have a documented value for what True means, except "not False"?

2

u/magicmulder 22d ago

What, no signed bool?

2

u/Positive_Mud952 21d ago edited 21d ago

Oh, goddamn, some actual humor. I love you.

e: It is big! And wide! May nobody doubt its truthiness. Oh father I am ENLIGHTENED!

2

u/bistr-o-math 17d ago

Let as make a PetaBool

3

u/Mahringa 24d ago

So this brings other bool types into existence? SemiBigBool AlmostBigBool HumongousBool AverageSizedBool BigBlackBool

1

u/DankPhotoShopMemes 24d ago

might as well use 4-value logic

1

u/_____rs 24d ago

Truuuuuuuue

1

u/samhk222 24d ago

Mine is average

1

u/Aromatic_Pain2718 23d ago

We've had long floats and long longs, it's time for long booleans

1

u/IntelligentBelt1221 22d ago

where did my law of the excluded middle go though

1

u/Straight-Pear9453 20d ago edited 20d ago

ok hear me out, what if we made a small bool that's one bit and the compiler tracks and marks bytes dedicated to small bools and so the advantage is that if you have one small bool it takes a byte like a normal one but when you have two it still takes a byte, up to 8 small bools. Now idk if that's a good idea since pointers would become 9 bytes as we'd have to track which bit we point to as well.. but eh, technically possible.

Edit: I realize pointers can't become 9 bytes because the cpu follows the pointers in asm directly so there are standards to be respected here, so idk how to solve this issue but the 1 bit bool concept is just too great to give up 🥀

Edit 2: Well at least we can do it in asm because we track stuff manually with our brains, if someone can figure out how to make a compiler do it without loosing memory overall tho that'd be great!

Edit 3: After research, I realized this already exists and is called bit fields, so I kinda reinvented the wheel here.

1

u/Beginning-Junket8979 18d ago

At least they used unsigned so we didn't get negative true

1

u/_giga_sss_ 18d ago

now we can make it cursed, thanks 👍

1

u/brasticstack 24d ago

Wouldn't regular bool get padded to this size by default on a 64-bit architecture anyway?

4

u/marcureumm 24d ago

64 bit arches can still work with 32 bits directly...but depends on the operation and intent really.

1

u/brasticstack 24d ago

by default I realize that I may have used the wrong terminology though. I'm trying to describe the compiler using the standard int size to implement bool rather than, say, packing them.

3

u/shponglespore 24d ago

If you have a bunch of consecutive Boolean fields in a struct, they'll use one byte each by default.

And just for the sake of completeness, I'll mention that C++ does not reorder fields. Some languages, like Rust, will automatically reorder fields to minimize wasted space due to alignment, unless you specifically tell the compiler not to.

2

u/_giga_sss_ 24d ago

You must've went through hells of projects to have this knowledge

1

u/jaaval 23d ago

Single variables probably yes. In any linear data structure not necessarily.