Discussion:
opposite of |=
(too old to reply)
Peter
2007-11-15 21:06:51 UTC
Permalink
Some Windows API functions take a DWORD (e.g. dwFlags) as input and you can
for instance build that variable by adding parts during a process that
determines the best combination:
E.g. dwFlags |= DO_OR_DONT_DO_STUFF ;

Now, what if I want to remove a part again ?
What does the exact opposite of |= (regardless if that part was already set
or not) and leaves all the rest intact ?
Remy Lebeau (TeamB)
2007-11-15 21:15:22 UTC
Permalink
Post by Peter
Now, what if I want to remove a part again ?
Use the '&' and '~' operators, ie:

dwFlags &= ~DO_OR_DONT_DO_STUFF ;


Gambit
Peter
2007-11-15 21:22:48 UTC
Permalink
Thanks !
Post by Remy Lebeau (TeamB)
Post by Peter
Now, what if I want to remove a part again ?
dwFlags &= ~DO_OR_DONT_DO_STUFF ;
Gambit
Vladimir Grigoriev
2007-12-06 14:30:56 UTC
Permalink
Well, let assume that dwFlags == DO_OR_DONT_DO_STUFF . So after the
operation
dwFlags != DO_OR_DONT_DO_STUFF
we will get that
dwFlags == DO_OR_DONT_DO_STUFF
will not?

However after the proposed *inverse* operation

dwFlags &= ~DO_OR_DONT_DO_STUFF

we will get that dwFlags will not be equal to its original value
DO_OR_DONT_DO_STUFF ! :)

Vladimir Grigoriev
Post by Remy Lebeau (TeamB)
Post by Peter
Now, what if I want to remove a part again ?
dwFlags &= ~DO_OR_DONT_DO_STUFF ;
Gambit
Vladimir Grigoriev
2007-12-06 14:35:24 UTC
Permalink
Post by Vladimir Grigoriev
Well, let assume that dwFlags == DO_OR_DONT_DO_STUFF . So after the
operation
dwFlags != DO_OR_DONT_DO_STUFF
we will get that
dwFlags == DO_OR_DONT_DO_STUFF
will not?
However after the proposed *inverse* operation
dwFlags &= ~DO_OR_DONT_DO_STUFF
we will get that dwFlags will not be equal to its original value
DO_OR_DONT_DO_STUFF ! :)
Vladimir Grigoriev
So the answer to the question is not correct. I think the question should be
asked another way. Instead of
"What does the exact opposite of |= (regardless if that part was already set
or not) and leaves all the rest intact ?"
How can I clear the bits which were set with the operation |=?

Vladimir Grigoriev
Remy Lebeau (TeamB)
2007-12-06 17:34:40 UTC
Permalink
Post by Vladimir Grigoriev
So the answer to the question is not correct.
Yes, it is. Peter asked how to remove DO_OR_DONT_DO_STUFF from dwFlags
without removing anything else. The answer I gave him is the correct
solution to that question.
Post by Vladimir Grigoriev
I think the question should be asked another way.
It doesn't matter how you phrase it. The end effect is still the same, and
so is the code for it.
Post by Vladimir Grigoriev
Instead of "What does the exact opposite of |= (regardless if that
part was already set or not) and leaves all the rest intact ?"
How can I clear the bits which were set with the operation |=?
The answer I gave earlier is the same to that question as well. Using "&="
and "~" will turn off the bits that "|=" turned on.


Gambit
Chris Uzdavinis (TeamB)
2007-12-06 17:45:57 UTC
Permalink
Post by Remy Lebeau (TeamB)
The answer I gave earlier is the same to that question as well. Using "&="
and "~" will turn off the bits that "|=" turned on.
That's *true*, but it's not complete, because &= may turn off some
bits that |= did not turn on (because they were already on.)
--
Chris (TeamB);
Remy Lebeau (TeamB)
2007-12-06 18:48:48 UTC
Permalink
Post by Chris Uzdavinis (TeamB)
That's *true*, but it's not complete, because &= may turn off some
bits that |= did not turn on (because they were already on.)
Perhaps, but that is not what Peter originally asked for.

If the code really needs to be sensitive to what "|=" actually turned on,
then it has to keep track of the changed bits manually, ie:

DWORD dwOriginal = dwFlags;
dwFlags |= DO_OR_DONT_DO_STUFF;

DWORD dwChangedBits = dwOriginal ^ dwFlags;
//...
if( dwChangedBits != 0 )
dwFlags &= ~dwChangedBits;


Gambit
Remy Lebeau (TeamB)
2007-12-06 17:31:32 UTC
Permalink
Post by Vladimir Grigoriev
Well, let assume that dwFlags == DO_OR_DONT_DO_STUFF .
So after the operation
dwFlags != DO_OR_DONT_DO_STUFF
"!=" and "|=" are not the same thing. One is a comparison, the other is an
assignment.
Post by Vladimir Grigoriev
we will get that
dwFlags == DO_OR_DONT_DO_STUFF
will not?
I'm not sure what you are trying to ask exactly.
Post by Vladimir Grigoriev
However after the proposed *inverse* operation
dwFlags &= ~DO_OR_DONT_DO_STUFF
we will get that dwFlags will not be equal to its original value
DO_OR_DONT_DO_STUFF ! :)
Of course not. The original value had DO_OR_DONT_DO_STUFF enabled. After
"&=" and "~", DO_OR_DONT_DO_STUFF is removed from the value. That is the
whole point of using them. And that is what Peter asked for.


Gambit
Chris Uzdavinis (TeamB)
2007-12-06 17:44:11 UTC
Permalink
Post by Remy Lebeau (TeamB)
Post by Vladimir Grigoriev
Well, let assume that dwFlags == DO_OR_DONT_DO_STUFF .
So after the operation
dwFlags != DO_OR_DONT_DO_STUFF
"!=" and "|=" are not the same thing. One is a comparison, the other is an
assignment.
Post by Vladimir Grigoriev
we will get that
dwFlags == DO_OR_DONT_DO_STUFF
will not?
I'm not sure what you are trying to ask exactly.
I think he's trying to show the difference between "undoing" the |=
operator, and unsetting the corresponding bits.

The distinction is only evident when the bits are ALREADY set, prior
to ORing some more in with them. If you undo the |= operator, it
would only change bits that actually changed on the way in, but
unsetting the corresponding bits may leave the original value in a
different state.

For example, let's use a 3-bit binary number, and assume that we can
write binary literals with a 'b' suffix:

var = 110b;
mask = 111b;

var |= mask; // var now 111b (only changes 1 bit)


NOW: "Undo" will revert var to 110b, but unsetting the bits that the
mask OR'd in will revert var to 000b. His main point is this:

"ORing in a set of bits, then ANDing them out does NOT necessarily
leave the value in the original state."

I had to read his post several times to get what he was trying to
point out, but this is what i think it was.
--
Chris (TeamB);
Vladimir Grigoriev
2007-12-07 09:28:02 UTC
Permalink
Post by Chris Uzdavinis (TeamB)
"ORing in a set of bits, then ANDing them out does NOT necessarily
leave the value in the original state."
I had to read his post several times to get what he was trying to
point out, but this is what i think it was.
--
Chris (TeamB);
Yes, I tried to say that. :)

Vladimir Grigoriev

Continue reading on narkive:
Loading...