2011-03-24 61 views
5

今天我花了一些時間追查兩個bug,最後使用相同的解決方案修復了它們。將NSNumber與NSInteger比較

既然我有解決方案,我希望能夠弄清楚它的背後。

我正在比較核心數據(Integer 16/NSNumber)與整數(ABPropertyID & ABMultiValueIdentifier)的屬性。

這個錯誤是在這個比較中,奇怪的是,只有在我殺了應用程序(從後臺托盤)後重新打開應用程序,然後運行包含比較的相同過程。反正...

這是停止後重新啓動工作:

if (myNumber.aProperty == [NSNUmber numberWithInt:anInteger]) { /* do stuff here */ }

而且這是兩個解決方案,到目前爲止,完美工作:

if ([myNumber.aProperty integerValue] == anInteger) {/* do stuff here */ }

if ([myNumber.aProperty isEqualToNumber:[NSNumber numberWithInt:anInteger]]) { /* do stuff here */ }

對我來說,它們看起來都是一樣的。我總是將NSNumber轉換爲integerValue,或將整數轉換爲NSNumber。

任何想法?

回答

11

請勿使用==來比較NSNumber s。大多數時候你會比較兩個不同的對象,所以比較結果不會是真實的。如果你看看你的條件,注意你特別比較你的財產和全新的NSNumber對象。

由於NSInteger是某種價值類型的可可包裝,比較NSInteger s與==工作正常。

isEqualToNumber:的執行可能需要包裝的值類型並進行比較。

+1

這是有道理的。有一件事很奇怪,但在我的文章中簡單提到,事實上,當我第一次運行我的應用時,這種比較實際上是有效的。只是在我殺了我的應用程序後,重新打開它,並通過比較運行應用程序,我開始看到意外的結果。在不瞭解我的應用程序或看到任何代碼的情況下,你會猜測爲什麼會發生這種情況? – djibouti33 2011-03-24 06:19:41

+0

@ djibouti33:不是線索......(並且說這個我也指出了它的不可預測性:) – BoltClock 2011-03-24 06:21:08

2

正如你所說,這兩個解決方案正在...

我寧願第一個,因爲它似乎更具可讀性,恕我直言...... 這也可能是更好的性能,因爲你是比較整數,在將一個NSNumber轉換爲一個int之後。

在第二個,你轉換一個int到一個對象,那麼你比較兩個對象... 所以這是第二個方法調用,你不會在第一種情況下有...

希望這有助於...:)

1

netWorkingButtonsIndexes是保持對象和 LinkedInint數據類型的編號的數組。

[[netWorkingButtonsIndexes objectAtIndex:buttonIndex] isEqual:[NSNumber numberWithInteger:LinkedIn]] 

通過使用isEqual方法,我們可以將對象與任何數據rtype進行比較。