Qustion about bitwise-AND-assign
We have a slight misunderstanding hinging on the use of the word "using". What I meant was, although a bool occupies a certain number of bits/bytes in memory, operations on it must not necessarily "use" or "depend on" all those bits.
Quote:Original post by Bnty_Hntr
If you use code and check EVERY possible way things could be, then it will work EVERY time. Now, in this case that proof is simple since bool only has two values, true and false.
[...]
So, it works. There ya go. Next time you can try thiskind of method before asking. Otherwise, if you can't figure it out this way, come on back.
But I just gave an example where the result is not what you'd expect. Granted, it took a bit of malicious reinterpret_casting to make it not work, but at the end of the day bitwise operators and bools just don't mix very well.
Quote:Original post by Red AntQuote:Original post by Bnty_Hntr
If you use code and check EVERY possible way things could be, then it will work EVERY time. Now, in this case that proof is simple since bool only has two values, true and false.
[...]
So, it works. There ya go. Next time you can try thiskind of method before asking. Otherwise, if you can't figure it out this way, come on back.
But I just gave an example where the result is not what you'd expect. Granted, it took a bit of malicious reinterpret_casting to make it not work, but at the end of the day bitwise operators and bools just don't mix very well.
Apparently, if you are able to prove that in EVERY possible case, the answer is correct then it will always be correct. In my case, using straight bool values, I proved EVERY possible case and therefore it must be correct.
Now, if you want to mess around with reinterpret_casting then it isn't always true.
So, in the end, if you are working with ONLY bool values, and not casting back and forth (even though I have no idea why you would), the method should be fine. Although, I also don't know why using && would make any difference in code anyway.
I would prefer
someBool &= someOtherBool;
to
someBool = someBool && someOtherBool;
anyday.
Quote:Original post by TDragon
We have a slight misunderstanding hinging on the use of the word "using". What I meant was, although a bool occupies a certain number of bits/bytes in memory, operations on it must not necessarily "use" or "depend on" all those bits.
Ah, yes. Well, yes, all the implementations of bool I know of only use the lowest-order bit, and keep everything else 0. That simplifies conversion **TO** integer. As for conversion **FROM** integer, it's also convenient because many CPU architectures have opcodes which signal boolean results as 0 or 1. Of course, this may cause bad craziness if someone manages to put something other than 0 or 1 in the memory space of a bool.
Quote:Original post by Bnty_Hntr
I would prefer
someBool &= someOtherBool;
to
someBool = someBool && someOtherBool;
anyday.
o rly? Tell me: What does dontQuitYet &= GetMessage(...); do? Hint: GetMessage is defined as BOOL GetMessage(LPMSG lpMsg, HWND hWnd, UINT wMsgFilterMin, UINT wMsgFilterMax).
for( char c = -128 ; c < 127 ; ++c ){ bool *bo = (bool*)&c; if( *bo ) cout << "true" << endl; else cout << "false" << endl;}outs a whole load of "true"'s and one "false". i assume the false is when it hits zero :)
Quote:Original post by rip-off
outs a whole load of "true"'s and one "false". i assume the false is when it hits zero :)
On your particular version of your particular compiler, with your particular compilation settings, given the particular current phase of the moon and the current price of a cheeseburger in Laos. Such tests are not useful for determining general behavior.
Author
Well, I did in fact draw the logic table, and I tested it with my interpreter, and both of those gave me 'yes, they are equivalent.' So possibly my question was phrased a little badly; I should have asked, 'Is this true by guarantee, or is it a quirk of my compiler?'
Quote:Original post by Bnty_Hntr
...
I would prefer
someBool &= someOtherBool;
to
someBool = someBool && someOtherBool;
anyday.
Then use this:
someBool &&= someOtherBool;
Apologies for any thread derailing that happened. The general consensus seems to be "quirk of the compiler" or, better, "don't rely on it".
EDIT: Okay, actually what you originally posted appears to be guaranteed true, but the intervening variations confused me. That seems to happen fairly often. Just pretend I never posted anything, 'kay? mkay.
EDIT: Okay, actually what you originally posted appears to be guaranteed true, but the intervening variations confused me. That seems to happen fairly often. Just pretend I never posted anything, 'kay? mkay.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
