2016-12-01 77 views
-1

由於某些原因,以下兩個按位運算提供了不同的結果,但由於使用的掩碼應該相同,所以它們應該提供相同的結果似乎很直觀。我在這裏錯過了什麼?爲什麼使用這兩種口罩的結果會有所不同?按位運算符的輸出之間的差別

public class BitShiftTest { 

    private long bitString = -8784238533840732024L ; 
    private final int MAX_BITS_POSITION = 63 ; 

    public static void main(String[] args) { 
     BitShiftTest bst = new BitShiftTest() ; 
     System.out.printf("Before applying mask: %s\n", Long.toBinaryString(bst.bitString)); 
     System.out.printf("Using Mask 1: %s\n", Long.toBinaryString(bst.clearBitMask(60))); 
     System.out.printf("Using Mask 2: %s\n", Long.toBinaryString(bst.clearBitMaskAlternative(60))); 
    } 

    public long clearBitMask(int position) { 
     return bitString & ~(1 << position) ; 
    } 

    public long clearBitMaskAlternative(int position) { 
     return bitString & (0x8000000000000000L >>> MAX_BITS_POSITION - position) ; 
    } 
} 

產生的結果是

Before applying mask: 1000011000011000000111011001100000101000001000000000000010001000 
Using Mask 1: 1000011000011000000111011001100000101000001000000000000010001000 
Using Mask 2: 0 
+3

不要修改'bitString'第一請撥打電話 – qxz

+0

對不起,我應該清除每個'clearBitMask ...'函數中的位串修改,但是我仍然得到相同的尷尬結果 – reayn3

+0

究竟是什麼結果? – RealSkeptic

回答

0

你假設~(1<<position)0x8000000000000000L >>> MAX_BITS_POSITION - position是相等的,但事實並非如此。

基本上,在另一種情況下你錯過了~--否則它看起來好像你只是試圖提取一個位,而不是清除它。它應該是:

~(0x8000000000000000L >>> MAX_BITS_POSITION - position) 

而且,正如@RolandIllig 1 << position注意到INT算術實際上是完成的。你在輸出中沒有看到這一點,因爲在你屏蔽的那一段時間內,第60或第28位都不會被設置。 1L << position解決了這個問題。

+0

好醇優先!所以實際上,如果掩碼用於類似的數據類型,那麼'〜(1 <<位置)'應該等於'(0x8000000000000000L >>>(MAX_BITS_POSITION - position))',對嗎? – reayn3

+0

@你有優先權錯誤。 –

+0

謝謝@RolandIllig。它看起來好像在面具上使用'1L'來排序 – reayn3

0

1 << 63int類型,因此等於Integer.MIN_VALUE,因爲1被移出數字。 (在其他語言中的結果將是不確定的,因爲你用更多的比特比int轉移了。

爲了解決這個問題,使用1L << 63,這對long工作。

+0

謝謝羅蘭。使用'bitString&〜(1L << position)'給出'bitString&〜(1 <<位置)'沒有的預期結果。然而,'bitString&(0x8000000000000000L >>>(MAX_BITS_POSITION - position))'仍然返回一個不正確的值,儘管它看起來類似於'bitString&〜(1L <<位置)' – reayn3

+1

你得到['1 << 63 '錯](http://ideone.com/jOU7Zz)。但是這不是計算! –

+0

@安迪謝謝,我糾正了它。 –