Bregma is this diagram similar to your explanation of a|=b?

Indeed it is.

Bitwise operators and Bit Masks.

(To be pedantic, bools don't have a number of bits, but instead undergo integer promotion when placed in the context of bitwise operators, where true is promoted to 1 and false is promoted to 0.)

(To be pedantic, bools don't have a number of bits, but instead undergo integer promotion when placed in the context of bitwise operators, where true is promoted to 1 and false is promoted to 0.)

(except when they don't. like when some asshole vendor has decided to store flags in the other 31 bits of their boolean)

(I will be scarred for the rest of my life)

That's why I don't like it when people can't just use the integrated bool type. It seems like every lib that comes along these days has to have its own proprietary bool.

That's why I don't like it when people can't just use the integrated bool type. It seems like every lib that comes along these days has to have its own proprietary bool.

That *was* the integrated bool type.

See, C++ doesn't really enforce many rules. And if you happen to know that on your platform, the compiler allocates 4 bytes for a bool, then you can *(int)&booleanValue, and proceed to manipulate the bits...

That's why I don't like it when people can't just use the integrated bool type. It seems like every lib that comes along these days has to have its own proprietary bool.

That *was* the integrated bool type.

See, C++ doesn't really enforce many rules. And if you happen to know that on your platform, the compiler allocates 4 bytes for a bool, then you can *(int)&booleanValue, and proceed to manipulate the bits...

See, C++ doesn't really enforce many rules. And if you happen to know that on your platform, the compiler allocates 4 bytes for a bool, then you can *(int)&booleanValue, and proceed to manipulate the bits...

This is actually very dangerous when doing language interop, even when the boolean types have the same size. C/C++ would seem to assume that 0 is false and anything else is true, but it is by no means certain that this is the same for all languages. For instance some other languages consider even = false and odd = true (i.e. they look only at the least significant bit, which imho makes more sense, but whatever). In these situations if you hack your "boolean" variable to equal, say, 42 in C++, this will evaluate to true in C++ but false in that other language. And it's not fun to debug.

It happened to me once. I was wondering why the boolean returned by a call to a C++ library I used from Pascal years ago didn't evaluate to what it should have. Turned out their idea of a boolean was not true/false but more like true/false + handle to some internal structure (because apparently, returning that handle by reference wasn't good enough and they needed to squeeze a copy in the return value "for my convenience"). /sigh

But this all goes with the rest.. people trying to be clever by finding loopholes in the standard and ending up shooting themselves (or, preferably, their users) in the foot.

This is actually very dangerous when doing language interop, even when the boolean types have the same size. C/C++ would seem to assume that 0 is false and anything else is true, but it is by no means certain that this is the same for all languages.

Bingo.

Proprietary embedded chip, with 4-byte native alignment, and a CMP instruction that only looked at the least-significant bit.