3 回答

TA貢獻1815條經驗 獲得超10個贊
-1將始終轉換為最大無符號值,這是由于“ 4.7 整數轉換”部分所致:
如果目標類型是無符號類型,則結果值是與源整數一致的最小無符號整數(取模2n,其中n是用于表示無符號類型的位數)。[注意:在二進制補碼表示中,此轉換是概念性的,并且位模式沒有任何變化(如果沒有截斷)。—尾注]
C99的相同報價來自6.3.1.3:
否則,如果新類型是無符號的,則通過重復添加或減去比新類型中可以表示的最大值多一個值來轉換該值,直到該值在新類型的范圍內為止。49)
因此,我們最終得到:
-1 + (UMAX + 1)
這是:
UMAX

TA貢獻1788條經驗 獲得超4個贊
明顯的警告在于一組元素的大小等于可能的最大大小。在實踐中發生這種情況的可能性和可用性,并且實際上實際上是造成問題的原因。
如果您查看C ++ std::string
類,您會注意到static std::string::npos
數據成員被定義為完全-1
轉換為std::string::size_type
(實際上只是std::size_t
。)這給該“技術”帶來了優先感,使它能夠完成“ Least Surprise?”的原理。永遠是一件好事?。
現在,-1
直接在這樣的比較中使用會帶來麻煩。您應該(視std::string
情況而定)確保此值有一個可訪問的名稱,以確保其特殊含義。不幸的是,C ++類型系統還不夠嚴格,無法防止用戶用腳射擊自己,但是至少堅持記錄的最佳實踐的用戶不會想到做不同的事情。

TA貢獻1880條經驗 獲得超4個贊
在嘗試思考可能會出問題的方式之后,我意識到調用函數可能會隱式地將返回值強制轉換為更大的類型(即,將unsigned int轉換為unsigned long long)。然后檢查該值== -1是否為假。
比較安全的選擇是顯式使用size_t.max作為前哨值。我總是對在有符號和無符號類型之間進行轉換感到不舒服。有時我認為更合理的方法是使所有內容都簽名(就像Java一樣)。
- 3 回答
- 0 關注
- 809 瀏覽
添加回答
舉報