On the complement 0 extension and the complement sign bit extension in Java

Today, Wei a problem, the title is as follows:

Define a byte[]a={-1,-2,-3,-4} of a large head order and convert it to short[]b. Q b[0] and b[1] What are the differences?

At first glance, the problem is not difficult, but the shift operation, and then the combination. But what? For the children's shoes in Java, there is a pit, a little attention may be stepping in. Before I say it, I'll post the code and answer it.

See here, may have children's shoes is more strange, why to &0xff, this is not the equivalent of no change? No, don't believe me, for instance.

The answer is-127 and 129. It's weird, isn't it? I think all of them are-127 AH!!!

Before we answer this question, let us first note that the type of B1 is int, not byte, because after any calculation of byte, the concept is defined by default to int.

Then, the play came, the University of computer composition principle we have learned the original code, anti-code and complement, the concept of the problem here do not say, also do not want to book those definitions, to learn, a picture to explain the problem.

Isn't it easy? One more thing to emphasize here is that there are only a few symbols in Java! There are only signed numbers in Java! There are only signed numbers in Java! Important thing to say three times!

Well, the value stored in Java is like this big disk!

Let's see why output 129? It is known that the byte after calculation will become an int, but someone else int is 32 bits of Ah, byte is only 8, so can only fill the place, eh ah, the question comes, how to fill it? This is what I want to emphasize today!

B is a byte type, and its computer is stored with a complement of 10000001 (8 bits).

After turning int, the extension in Java is the complement sign bit extension, what is the complement symbol bit extension? It turns out to be 11111111 11111111 11111111 10000001 (32-bit), so why change? Because this change is still-127, the value size does not change!

And what if we &0xff? b&0xff=11111111 11111111 11111111 10000001&11111111=00000000 00000000 00000000 10000001, this value is 129, this is the patch 0 extension! So 129 of the problem solved!

What the? What is the use of 0 extension? We go back to the Wei problem, two byte synthesis a short,short but 16 oh, if we do not &0xff, that is written

S[1] = (short) ((Bs[2] << 8) | bs[3]);

The output turns out to be-4. Why is it?

Or just that idea Ah, bs[2] is-3, that is 11111101,bs[3] is-4, that is 11111100,

(Bs[2] << 8) becomes 11111111 11111111 11111101 00000000,

((Bs[2] << 8) | bs[3]) it becomes 11111111 11111111 11111101 00000000 | 11111111 11111111 11111111 11111100 = 11111111 11111111 11111111 11111100,

Turn to short, that is 11111111 11111100, the result is-4! Just Jiangzi!

So the code in Java that converts between byte and short should be:

//Short to byte Shortx =-32752;//Define a shortbyteHigh = (byte) (0xFF & (x>>8));//defines the first bytebyteLow = (byte) (0xFF & x);//defines a second byteSystem.out.println (high);//print the first byte valueSYSTEM.OUT.PRINTLN (Low);//print a second byte value//byte turn short Shortz = ( Short) (((High & 0xFF) << 8) | (0xFF &Low )); System.out.println (z);//The result of the output is -32752.

Finally, summarize:

Because there are only signed numbers in Java, when a byte is extended to short, int, that is, the positive number is the same, because the sign bit is 0, so it is a 0 extension anyway, but the negative complement 0 extension and the sign bit extension result are completely different.

Fill the number of symbols, the original value is unchanged.

A fill zero is equivalent to the signed number as an unsigned number, such as -127 = 0x81, as unsigned number is 129, 256 + (-127).

For signed numbers, when you are growing from a small scale, you need to use &0XFF to ensure that you are expanding by 0.

From the large to small processing, the sign bit automatically invalid, so no processing.

On the complement 0 extension and the complement sign bit extension in Java