我對size_t的理解是，它足夠大，可以容納任何（整數）值，您可能認爲它需要保持。 （也許這是一個不好的解釋？）C++：是否有任何理由使用uint64_t，而不是size_t
例如，如果您使用類似for循環遍歷向量中的所有元素，size_t通常是64位長（或至少在我的系統上）爲了它可以從vector.size（）中保存所有可能的返回值。
或者至少，我認爲這是正確的？
因此，沒有任何理由使用，而不是B：
答：for(uint64_t i = 0; i < v.size(); ++ i)
B：for(size_t i = 0; i < v.size(); ++ i)
如果我錯了，我的解釋，或者你有更好的解釋，請隨時編輯。
編輯：我應該補充一點，我的理解是，size_t行爲像一個正常的無符號整數 - 也許這是不正確的？
正確的情況是for(std::vector::size_type i ...。
對於通過一個載體，或者諸如此類的東西迭代的目的，你將很難推到尋找到size_t不夠大的情況下，和uint64_t是，
當然，在32位機器，size_t通常是32位，但你可能想要處理大於40億的數字，這將需要超過32位，這當然是一個用例uint64_t。換言之，uint64_t保證是64位，size_t在所有機器/體系結構中不是64位。
size_t是返回式sizeof。
該標準說它是一些無符號整數類型的typedef，並且足夠大以容納任何可能的對象的大小。
但它並沒有要求它是更小，更大還是與uint64_t（固定寬度的64位無符號整數的typedef）相同的大小，在後一種情況下它也不是相同的類型。
因此，使用size_t其中語義正確。
喜歡的std::vector<T>的size()（std::vector得到它的從使用分配器size_type，std::allocator<T>使用size_t）。
沒有冒犯，但'std :: vector
是的，而且來自分配器。 – Deduplicator 2018-02-18 17:09:39
uint64_t保證是64位。如果你需要64位，你應該使用它
size_t不能保證是64位，在未來的一臺機器可能是128位。所以，關鍵字uint_64其保留的:)
應該「保證是」 – dtech 2015-02-23 23:51:45
std::size_t被定義爲無符號整數類型。它的長度取決於平臺。 v.size()將始終返回std::size_t類型的值，因此選項B總是正確的。
不，size_t與「持有您可能期望它需要保留的任何整數值」完全沒有關係。你從哪裏得到這個？
size_t應該足夠大以容納給定實現中的任何連續對象的字節大小。從概念上講，這比「任何整數值」少得多。該語言並不保證您可以創建佔用整個可尋址存儲的對象，這意味着size_t在概念上不足以保存可尋址的內存字節數。
如果您想將任意整數值與內存大小相匹配，那麼適當的類型將是uintptr_t，這在概念上大於size_t。但我認爲沒有任何理由將「任何整數值」與記憶特徵聯繫在一起。例如。即使uintptr_t大於size_t，但不能保證足夠大以保持平臺文件系統中最大文件的大小。
您可以使用size_t迭代std::vector的元素的原因是該向量在內部基於數組。數組是連續的對象，這就是爲什麼它們的大小被size_t覆蓋。但是一旦考慮到非連續的容器，如std::list,size_t不再保證足以測量或索引這些容器。
uint64_t可以更容易大於size_t。但很有可能您必須使用不適合uint64_t的整數值。
'std :: malloc'和'std :: allocator'也使用'std :: size_t'。 – tmlen 2015-02-23 23:49:36
即使'uintptr_t'可能太小。由於OP描述中的值沒有限制...... – Deduplicator 2015-02-23 23:50:06
@tmlen：他們這樣做是因爲他們分配*連續的*內存塊，即他們分配字節數組。對他們來說，使用'size_t'完全合適。 – AnT 2015-02-23 23:51:08
如果您需要確保您的int無論出於何種原因（通常是字節操作）都是64位。 'size_t'可以根據您的系統和編譯選項而有所不同 – 2015-02-23 23:37:09
'size_t'不能保證是64bit – dtech 2015-02-23 23:46:56
如果您在32位目標上使用'uint64_t'，那麼性能可能會遠遠低於最佳性能。 – sharptooth 2016-03-15 07:04:22