How do Bitwise Operators work?
Hi everybody
I know a little bit of bitwise operators and I am getting some problems working with them.
For example, imagine the byte 0x42 (Or 01000010). Now I want to build a long having this byte on the first position starting from the left so I try the following code:
long l = 0x42 << 56;
However, this operation seems to work like if I have written:
long l = 0x42 << 24
That is, the new long is a String of only 32 bits. Why does this command ignore the first 32 bits? Any ideas?
[605 byte] By [
astu18a] at [2007-11-27 11:50:17]

> It works!
Do you understand why?
~
Not at all. Can you explain it?
The reason, by the way, is that the expression 0x42 << 56 has type int --
its assignment to a long variable doesn't influence an expression's type.
Ok. Now I understand it. Thank you very much for your help.
On a small tangent, I asked this question yesterday: what does this program output?
Guess, then copy and run to see if you were right.
public class PartyPretzel {
public static void main(String[] args) {
System.out.println(12345 + 5432l);
}
}
> On a small tangent, I asked this question yesterday:
> what does this program output?
Grooooooooovy.
~
> On a small tangent, I asked this question yesterday:
> what does this program output?
> Guess, then copy and run to see if you were right.
> > public class PartyPretzel {
>public static void main(String[] args) {
>System.out.println(12345 + 5432l);
> }
> }
>
Wauu. I would have bet my hand saying that the result will be 66666 and it is 17777. And the reason for this is....
> > On a small tangent, I asked this question
> yesterday:
> > what does this program output?
>
> Grooooooooovy.
A haunted JVM?
> And the reason for this is....
Lack of attention to detail? ;o)
@BDLH: How do you get the code tags not to screw that up?
~
I would say because the numbers are greater than the maximum integer value. Am I right?
> I would say because the numbers are greater than the
> maximum integer value. Am I right?
Nope. 66666 is not that big, is it? Integer.MAX_VALUE is 2147483647
> I would say because the numbers are greater than the
> maximum integer value. Am I right?
No. Not by a long shot.
Hint: It relates to the original problem in this thread.
jverda at 2007-7-29 18:30:31 >

> I would say because the numbers are greater than the
> maximum integer value. Am I right?
Good guess, but not correct.
1 != l
~
> @BDLH: How do you get the code tags not to screw that up?
I'll tell you when the cat is out of the bag.
> I'll tell you when the cat is out of the bag.
I may have opened the bag... o_O
~
> @BDLH: How do you get the code tags not to screw that
> up?
Double it up, not?
jverda at 2007-7-29 18:30:31 >

> > @BDLH: How do you get the code tags not to screw
> that up?
>
> I'll tell you when the cat is out of the bag.
Okay: that stupid filter strips off the suffix if you write 5432l, so you have to write 5432ll
Ok. Then maybe the numbers 12345 and 54321 are not written in a decimal scale?
Come on guys. What's the reason for the strange output? I'm dying to know...
> Ok. Then maybe the numbers 12345 and 54321 are not
> written in a decimal scale?
The number 54321 is not present in that code.
Both numbers are decimal.
jverda at 2007-7-29 18:30:31 >

Copy paste the code.
Change the println and get rid of the "12345 + " part.
Run it.
System.out.println(5432l);
jverda at 2007-7-29 18:30:31 >

XD
Ok. I see. Good joke guys. I will use it with my partners!
> > long l = 0x42 << 56;
>
l is a really bad variable name, by the way. :-)
jverda at 2007-7-29 18:30:31 >

Credits: I stole that example from Joshua Bloch and Neal Gafter, authors of the book Java Puzzlers.
Check out their Vodcast (May 18, 2007)
http://java.sun.com/developer/media/
In the discussion, they admit people hiss and groan with this particular puzzle.
I really thought it was a Java problem/trick as oppose to mistyping problem. Not funny........waste of time!!
> l is a really bad variable name, by the way. :-)
I know. It was just for the example. I never use those names for the variables.
> l is a really bad variable name, by the way. :-)
It's a really good variable name. Rule #22:
http://mindprod.com/jgloss/unmainnaming.html
~
> In the discussion, they admit people hiss and groan
> with this particular puzzle.
Reply #28. :o)
~