我正在使用的庫需要在32位和64位計算機上使用;我有很多編譯器警告，因爲在64位機器上unsigned int != size_t。使用unsigned long替換size_t的缺點是什麼
用'unsigned long'取代所有unsigned int s和size_t s有什麼不足嗎？我感謝它看起來不是很優雅，但是，如果出現這種情況，內存不是太大的問題......我想知道是否有可能發生此類replace all操作產生的任何錯誤/不需要的行爲（可能你舉例）？謝謝。
什麼警告？我能想到的最明顯的是「縮小轉換」，也就是說您將size_t分配到unsigned int，並獲得信息可能丟失的警告。
與unsigned long更換size_t的主要缺點是，unsigned long不能保證足夠大，以包含的size_t每一個可能的值，而在Windows 64它是不是足夠大。所以你可能會發現你仍然有警告。
正確的解決方法是，如果將size_t分配給變量（或數據成員），則應確保該變量的類型足夠大，以包含任何值size_t。這就是警告的全部內容。所以你不應該切換到unsigned long，你應該將這些變量切換到size_t。相反，如果您有一個變量不需要足夠大以容納任何大小，只要大到足以滿足unsigned int，那麼首先不要使用size_t。
兩種類型（size_t和unsigned int）具有有效的用途，因此，通過一些其他類型的不加區別地替換所有使用它們中的任何方法必須是錯誤的:-)其實，你可以用size_t或uintmax_t和取代一切大多數程序可以。例外情況是代碼依賴於使用與int相同大小的無符號類型，或者其他任何類型，例如較大的類型會破壞代碼。
如果您在使用的地方在那裏size_t你應該得到size_t與unsigned long取代它，你將引入新的警告。
例如：
size_t count = some_vector.size();
更換size_t與unsigned long，和（的程度，他們是不同的），你會引入了新的警告（因爲some_vector.size()返回size_t - 實際上是一個std:::vector<something>::size_type，但在實踐中，應評估到相同）。
我可能會得到更多的警告，但是可能會導致真正的麻煩（例如錯誤）？ – 2013-03-26 12:40:52
@YuccaV在任何認真對待自己的計劃中，警告都是真正的麻煩。 – Angew 2013-03-26 12:42:45
這取決於您的代碼。如果有 - 例如 - 計算偏移量的差異並比較它們是否小於零，則使用未簽名，您可能會將負值轉換爲無符號值，該值應該接近最大範圍附近的某個類型的無符號值（0x11111111或類似）。它基本上取決於你的代碼庫。然而，Angew的觀點是有效的：你最好的選擇是設置你的編譯器對警告有零容忍（對於gcc這就是'-Werror'選項）。 – utnapistim 2013-03-26 12:46:16
該標準對諸如int和long之類的尺寸幾乎沒有保證。 size_t保證足夠大以容納任何物體，並且所有std容器在size_t上運行。
這是完全有可能的平臺定義long爲小於size_t，或有long受到編譯選項的大小，例如。爲了安全起見，最好堅持size_t。
另一個要考慮的標準是size_t帶有一個含義 - 「這個東西用來存儲大小或索引。」它使代碼稍微更自我記錄。
如果在某些時候庫的規範發生變化並且'size_t'得到簽名，您將遇到很多麻煩。 – Spook 2013-03-26 12:36:08
發生這種情況的可能性是什麼？ size_t應該表示一個內存地址...... – 2013-03-26 12:37:45
一個缺點是在64位Windows上'size_t'是'unsigned long long'，因爲'long'只有32位（即使在64位模式下）。 – 2013-03-26 12:40:20