My brain at 5:00 AM

The byte was aligned to a 64 bit word. 63 bits are wasted.

Error correction, motherfucker, do you speak it?

@kamen Depends on implementation. Actual data could be anything.

In C, 255 used to be very common (because bitwise compares); I’m not sure about now.

Yup. Better use a VARCHAR(3) to store YES or No, to make that app more efficient. 🤣

I've actually seen that in a productive app.

@Root I've never seen the numeric representation of `true` be anything other than 1 in either C or C++.

Also, if you're doing a bitwise check against a logical value, you're doing it wrong.

@junon history is history. 🤷🏻‍♀️

@junon @root is talking about what the generated assembler does.

@Demolishun That doesn't make any sense. Have an example?

@root sorry didn't mean I thought you were being disingenuous, I should have added a question: which compilers did this, and when? Isn't it standardized to 1 now?

@junon I could see an instruction that sets a flag based upon the value of register precluding the need for a comparison. I have used instructions like this in PIC microcontrollers. Where you could have a loop that does not require a separate check to determine if the loop should continue running. Then again, maybe I am reading into the comment.

I fail to see how a memory cell being 255 would set a cpu flag. Perhaps if the architecture did so upon a read, or if you did an INC and checked for 8-bit overflow via CF, but then you could also just do a DEC and check for ZF.

Perhaps the MSB lane could be checked and set to the flag - but so could the LSB lane. Actually.... that'd be really useful.

Either way, I see less of a benefit, philosophically speaking, of treating 255 as true.

In fact, in C or C++, non-zero is boolean truthy, so it wouldn't make a lot of difference anyway unless you're doing arithmetic or bitwise operations on the value, which (again, philosophically) is not very smart.

@junon A lot of shit we used to do was to second guess the compiler. Modern compilers do a lot of shit making it so we don't have to trick it to create performant code. Heck we used to do bitshift multiplication just because it was faster.

~(0) is 255 hurr durr
Accept it.
255.
No waste.

@melezorus34 Only if your register is 8-bits...

It's possible to use bit size allocations in C++.

When I wrote a chess engine, it was about 3x faster to use a bit vector instead of an array of booleans.

That’s why you should always create flag registers of 8 boolean values you intend to track at once stored in a single integer to make sure you don’t lose the memory space.

Then you can write functions to grab the right binary big from it on demand because you forgot how to retrieve it otherwise!

@hashedram I'm very suspicious about that number. How were the booleans aligned? How large is sizeof(bool)? How large was the array? Did the array cross a cache line boundary? Bitsets are not free, on any platform. Cheap yes, but they are not inherently going to speed up execution unless there's an optimization around memory access.

If you're performing many operations on the same bitset then maybe it was a register promotion but I'd like to see the godbolt of whatever it is you did.

Also your first statement is wrong. You cannot allocate sub-byte memory. You probably meant bitwise operations, which... yes, of course you can.

@junon

Allocating bit fields in structs:

https://en.cppreference.com/w/cpp/...

There are also fields:

https://en.cppreference.com/w/cpp/...

Not sure how they are internally structured, but you can do boolean operations on fields independently. So I don't know what you mean by not being able to allocate bits. You can logically interact with independent bits that may or may not be in a byte with other bits. How is that not allocating individual bits?

@junon @Demolishun It’s been so long I simply don’t remember specifics. Also, I’ve seen the same behavior referenced by others here on devRant, so it’s not my brain fabricating memories.

@junon

1) It was years ago
2) I specifically measured it
3) Duh

@hashedram "Duh" is not how computer science works. Shameful approach to a discussion.

@junon meh