Wait until you hear about alignment
The alignment of the language and the alignment of the coder must be similar on at least one metric, or the coder suffers a penalty to develop for each degree of difference from the language's alignment. This is penalty stacks for each phase of the project.
So, let's say that the developer is a lawful good Rust ~~zealot~~ Paladin, but she's developing in Python, a language she's moderately familiar with. Since Python is neutral/good, she suffers a -1 penalty for the first phase, -2 for the second, -3 for the third, etc. This is because Rust (the Paladin's native language) is lawful, and Python is neutral (one degree of difference from lawful), so she operates at a slight disadvantage. However, they are both "good", so there's no further penalty.
The same penalty would occur if using C, which is lawful neutral - but the axis of order and chaos matches, and there is one degree of difference on the axis of good and evil.
However, if that same developer were to code in Javascript (chaotic neutral), it would be at a -3 (-6, -9...) disadvantage, due to 2 and 1 degree of difference in alignment, respectively.
Malbolge (chaotic evil), however, would be a -4 (-8, -12) plus an inherent -2 for poor toolchain availability.
..hope this helps. have fun out there!
Wait till you here about every ascii letter. . .
what about them?
ASCII was originally a 7-bit standard. If you type in ASCII, every leading bit is always 0
.
At least ASCII is forward compatible with UTF-8
Is ascii base-7 fandom's strongest argument...
Ascii needs seven bits, but is almost always encoded as bytes, so every ascii letter has a throwaway bit.
Let's store the boolean there then!!
This reminds me that I actually once made a class to store bools packed in uint8 array to save bytes.
Had forgotten that. I think i have to update the list of top 10 dumbest things i ever did.
Could a kind soul ELI5 this? Well, maybe ELI8. I did quite a bit of programming in the 90-00s as part of my job, although nowadays I'm more of a script kiddie.
A Boolean is a true/false value. It can only be those two values and there be represented by a single bit (1 or 0).
In most languages a Boolean variable occupies the space of a full byte (8 bit) even though only a single of those bits is needed for representing the Boolean.
That's mostly because computers can't load a bit. They can only load bytes. Your memory is a single space where each byte has a numeric address. Starting from 0 and going to whatever amount of memory you have available. This is not really true because on most operating systems each process gets a virtual memory space but its true for many microcontrollers. You can load and address each f these bytes but it will always be a byte. That's why booleans are stored as bytes because youd have to pack them with other data on the same address other wise and that's getting complicated.
Talking about getting complicated, in C++ a std::vector is specialized as a bit field. Each of the values in that vector only occupy a single bit and you can get a vector of size 8 in a single byte. This becomes problematic when you want to store references or pointers to one of the elements or when you're working with them in a loop because the elements are not of type bool but some bool-reference type.
boolean bloat
I first thought you wrote boolean float, not sure if that's even worse.
I mean is it really a waste? What's minimum amount of bits most CPUs read in one cycle.
In terms of memory usage it's a waste. But in terms of performance you're absolutely correct. It's generally far more efficient to check is a word is 0 than to check if a single bit is zero.
In the industrial automation world and most of the IT industry, data is aligned to the nearest word. Depending on architecture, that's usually either 16, 32, or 64 bits. And that's the space a single Boolean takes.
That's why I primarily use booleans in return parameters, beyond that I'll try to use bitfields. My game engine's tilemap format uses a 32 bit struct, with 16 bit selecting the tile, 12 bit selecting the palette, and 4 bit used for various bitflags (horizontal and vertical mirroring, X-Y axis invert, and priority bit).
Bit fields are a necessity in low level networking too.
They're incredibly useful, I wish more people made use of them.
I remember I interned at a startup programming microcontrollers once and created a few bitfields to deal with something. Then the lead engineer went ahead and changed them to masked ints. Because. The most aggravating thing is that an int size isn't consistent across platforms, so if they were ever to change platforms to a different word length, they'd be fucked as their code was full of platform specific shenanigans like that.
/rant
Or you could just use Rust
I always use stdint.h so that my types are compatible across any mcu. And it makes the data type easily known instead of guessing an i t size
Back in the day when it mattered, we did it like
#define BV00 (1 << 0)
#define BV01 (1 << 1)
#define BV02 (1 << 2)
#define BV03 (1 << 3)
...etc
#define IS_SET(flag, bit) ((flag) & (bit))
#define SET_BIT(var, bit) ((var) |= (bit))
#define REMOVE_BIT(var, bit) ((var) &= ~(bit))
#define TOGGLE_BIT(var, bit) ((var) ^= (bit))
....then...
#define MY_FIRST_BOOLEAN BV00
SET_BIT(myFlags, MY_FIRST_BOOLEAN)
Okay. Gen z programmer here. Can you explain this black magic? I see it all the time in kernel code but I have no idea what it means.
The code is a set of preprocessor macros to stuff loads of booleans into one int (or similar), in this case named 'myFlags'. The preprocessor is a simple (some argue too simple) step at the start of compilation that modifies the source code on its way to the real compiler by substituting #defines, prepending #include'd files, etc.
If myFlags is equal to, e.g. 67, that's 01000011, meaning that BV00, BV01, and BV07 are all TRUE and the others are FALSE.
The first part is just for convenience and readability. BV00 represents the 0th bit, BV01 is the first etc. (1 << 3) means 00000001, bit shifted left three times so it becomes 00001000 (aka 8).
The middle chunk defines macros to make bit operations more human-readable.
SET_BIT(myFlags, MY_FIRST_BOOLEAN)
gets turned into ((myFlags) |= ((1 << 0)))
, which could be simplified as myFlags = myFlags | 00000001
. (Ignore the flood of parentheses, they're there for safety due to the loaded shotgun nature of the preprocessor.)
It's called bitshifting and is used to select which bits you want to modify so you can toggle them individually.
1 << 0 is the flag for the first bit
1 << 1 for the second
1 << 2 for the third and so on
I think that's correct. It's been years since I've used this technique tbh 😅
I swore I read that mysql dbs will store multiple bools in a row as bit maps in one byte. I can't prove it though
I recall that sql server will group bit columns into bytes for storage, wouldn't surprise me if other flavours did something similar.
SIMD Might be the term youre looking for (Single Input Multiple Data)
typedef struct {
bool a: 1;
bool b: 1;
bool c: 1;
bool d: 1;
bool e: 1;
bool f: 1;
bool g: 1;
bool h: 1;
} __attribute__((__packed__)) not_if_you_have_enough_booleans_t;
I set all 8 bits to 1 because I want it to be really true.
01111111 = true
11111111 = negative true = false
negative true = negative non-zero = non-zero = true.
Are you telling me that no compiler optimizes this? Why?
It would be slower to read the value if you had to also do bitwise operations to get the value.
But you can also define your own bitfield types to store booleans packed together if you really need to. I would much rather that than have the compiler do it automatically for me.
CPUs don't read one bit a a time.
Well there are containers that store booleans in single bits (e.g. std::vector<bool>
- which was famously a big mistake).
But in the general case you don't want that because it would be slower.
Why is this a big mistake? I’m not a c++ person
The mistake was that they created a type that behaves like an array in every case except for bool
, for which they created a special magical version that behaves just subtly different enough that it can break things in confusing ways.
Could you provide an example?
Depending on the language
And compiler. And hardware architecture. And optimization flags.
As usual, it's some developer that knows little enough to think the walls they see around enclose the entire world.
Wait till you find out about alignment and padding
Tell me the truth, i can handle it
Programmer Humor
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics