Scala中的>>和>>>之間的區別

Question

Scala中的>>和>>>運算符有什麼不同？

scala> 0x7f >>> 1 
res10: Int = 63 

scala> 0x7f >> 1 
res11: Int = 63 

scala> 0x7f >> 4 
res12: Int = 7 

scala> 0x7f >>> 4 
res13: Int = 7 

Answer 1

的>>操作者保留符號（Sign-延伸），而>>>零的最左邊的位（零擴展）。

-10>>2 
res0: Int = -3 
-10>>>2 
res1: Int = 1073741821 

Try it out yourself.

這不是像C語言已簽署和無符號類型需要的，不像Java，它也有>>>（因爲它沒有無符號整數）。

Answer 2

它們與Java中的含義相同。帶符號的左移運算符「< <」將位模式向左移位，並且帶符號的右移運算符「>>」將位模式向右移位。位模式由左側操作數給出，並由右側操作數移動位置數量。無符號右移運算符「>>>」將零移動到最左邊的位置，而「>>」之後的最左邊位置取決於符號擴展。

Answer 3

注：與SLIP 30（11月2015），斯卡拉最終可能會（2016年2017年？）有4個 「原始」 類型來表示無符號整數：UByte，UShort，UInt和ULong。

這將影響Bit shifting operations on UInts and ULongs，這也說明了>>和>>>之間的區別：

左移<<，並在明顯的方式轉移邏輯正確>>>的行爲。

移位算術權>>的情況值得商榷。
我們認爲，這不應該是可利用的無符號整數，原因有二：

• 首先，移位運算權似乎並沒有對無符號整數任何意義。正確的算術移位如果>>>。因此，與unary_-類似，不應引入。
• 其次，現有的語言確實具有無符號整數類型，如C家，居然要>>給不同的語義取決於它是否有一個符號或無符號運算：在一個無符號運算
  一個>>不簽字-延伸。如果一個C開發人員在x >> 3簽名擴展到Scala中，會讓人感到困惑，但是對於Scala開發人員來說，x >> 3不會簽名擴展也會令人困惑。因此，我們寧願完全拋棄它，並讓編譯器出錯。

如果基於位變換算法需要的符號擴展右移，總是可以重新解釋爲簽署，做了手術，並重新解釋回爲無符號：(x.toInt >> 3).toUInt。

注意：目前的實施確實提供>>，直到我們達成這一觀點爲止。