[MISC] - Operators - Meaning of operator &
-
Dear everybody, I have a question about the meaning of & operator in the following expression: ((WORD)(((DWORD)(l) >> 16) & 0xFFFF)) 1) What role does the & operator do here ? 2) Why do programmers often use & with hexadecimal, not integer or long integer or double ? I'm looking forward to seeing your reply soon. Best regards, Jetflower
-
Dear everybody, I have a question about the meaning of & operator in the following expression: ((WORD)(((DWORD)(l) >> 16) & 0xFFFF)) 1) What role does the & operator do here ? 2) Why do programmers often use & with hexadecimal, not integer or long integer or double ? I'm looking forward to seeing your reply soon. Best regards, Jetflower
Thang wrote:
- What role does the & operator do here ?
Bitwise AND.
Thang wrote:
- Why do programmers often use & with hexadecimal, not integer or long integer or double ?
Bits, bytes, and words are easier to visualize in base-16.
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
-
Dear everybody, I have a question about the meaning of & operator in the following expression: ((WORD)(((DWORD)(l) >> 16) & 0xFFFF)) 1) What role does the & operator do here ? 2) Why do programmers often use & with hexadecimal, not integer or long integer or double ? I'm looking forward to seeing your reply soon. Best regards, Jetflower
Okay, lets say that l = 3131961357 This is the same as 0xBAADF00D Which is the same as 10111010101011011111000000001101 Which means your expression looks a little something like this: ((WORD)(((DWORD)(0xBAADF00D) >> 16) & 0xFFFF)) 3131961357 >> 16 = 47789 0xBAADF00D >> 16 = 0x0000BAAD 10111010101011011111000000001101 >> 16 = 00000000000000001011101010101101 47789 & 65535 = 47789 0x0000BAAD & 0x0000FFFF = 0x0000BAAD 00000000000000001011101010101101 & 00000000000000001111111111111111 = 00000000000000001011101010101101 Basically, the code simply takes a 32 bit number and returns the top (most significant) 16 bits of them. The >> 16 followed by the & 0xFFFF is unnecessary - the bitshift right 16 bits automatically fills the top 16 bits with 0s. This code is functionally the same: (WORD)((DWORD)(l) >> 16) See how much easier things are when we use hex/binary? Edited && --> &
-
Okay, lets say that l = 3131961357 This is the same as 0xBAADF00D Which is the same as 10111010101011011111000000001101 Which means your expression looks a little something like this: ((WORD)(((DWORD)(0xBAADF00D) >> 16) & 0xFFFF)) 3131961357 >> 16 = 47789 0xBAADF00D >> 16 = 0x0000BAAD 10111010101011011111000000001101 >> 16 = 00000000000000001011101010101101 47789 & 65535 = 47789 0x0000BAAD & 0x0000FFFF = 0x0000BAAD 00000000000000001011101010101101 & 00000000000000001111111111111111 = 00000000000000001011101010101101 Basically, the code simply takes a 32 bit number and returns the top (most significant) 16 bits of them. The >> 16 followed by the & 0xFFFF is unnecessary - the bitshift right 16 bits automatically fills the top 16 bits with 0s. This code is functionally the same: (WORD)((DWORD)(l) >> 16) See how much easier things are when we use hex/binary? Edited && --> &
We're lucky that
0XDEADBEEF != 0XBAADFOOD
This signature was proudly tested on animals.
-
We're lucky that
0XDEADBEEF != 0XBAADFOOD
This signature was proudly tested on animals.
-
Okay, lets say that l = 3131961357 This is the same as 0xBAADF00D Which is the same as 10111010101011011111000000001101 Which means your expression looks a little something like this: ((WORD)(((DWORD)(0xBAADF00D) >> 16) & 0xFFFF)) 3131961357 >> 16 = 47789 0xBAADF00D >> 16 = 0x0000BAAD 10111010101011011111000000001101 >> 16 = 00000000000000001011101010101101 47789 & 65535 = 47789 0x0000BAAD & 0x0000FFFF = 0x0000BAAD 00000000000000001011101010101101 & 00000000000000001111111111111111 = 00000000000000001011101010101101 Basically, the code simply takes a 32 bit number and returns the top (most significant) 16 bits of them. The >> 16 followed by the & 0xFFFF is unnecessary - the bitshift right 16 bits automatically fills the top 16 bits with 0s. This code is functionally the same: (WORD)((DWORD)(l) >> 16) See how much easier things are when we use hex/binary? Edited && --> &
Dear Mr enhzflep and Mr DavidCrow, First of all, thank you so much about your clearly explanation. I just still have a consideration, why the small expression (& 0xFFFF) has been still used in the expression ((l) >> 16) & 0xFFFF) here . And this expression origins from window library, hix. Why they still have used this expression if it was not necessary in here ? Once again, thanks for your help, Mr enhzflep and Mr DavidCrow. Best regards, Duong Quoc Thang
