使用 std::string::size_type 而不是 size_t 有什么好处吗？答案

【问题标题】：Is there any benefit to using std::string::size_type over size_t?使用 std::string::size_type 而不是 size_t 有什么好处吗？
【发布时间】：2012-05-18 04:51:44
【问题描述】：

我正在审查另一位开发人员的代码，其中包含以下内容：

std::string name;
...
std::string::size_type colon = name.find(":");

我认为使用size_t 会更容易理解并且同样安全，因为STL 标准规定std::string 是std::basic_string<char, std::allocator>，而std::allocator::size_type 是size_t。

他希望确保 STL 标准永远不会改变以使该假设无效；如果标准可以改变，那么size_type 会比size_t 更安全。

这会发生吗？还有其他理由使用size_type 而不是size_t？

【问题讨论】：

size_type 适合每个容器，无论它们使用什么类型，因此更加一致。
你可能会认为name 永远是一个真实的std::string。
没有“STL 标准”。 C++ 标准可能会改变，但是你会使用另一种语言（称之为“C++11”），它与你现在使用的语言并不完全向后兼容（称之为“ C++03")。将代码从 C++03 移植到 C++11 需要知道什么是重大变化，并考虑它们。所以如果你来到它，你可以穿过那座桥。在那之前，如果标准说它是真的，那么它就是真的。 IMO 标准不太可能以使用size_t 的大小破坏代码的方式发生变化，string 或vector 默认分配器的大小。
...您也可以推测未来的标准可能会将find 的返回类型更改为std::string::size_type 以外的其他类型。没有考虑到重大变化。
@SteveJessop - 我认为你的第二点特别相关。是的，string::size_type 可以改变，但string::find() 也可以。很好，谢谢！

标签： c++ stl size-type

【解决方案1】：

size_type 应该用于在容器类型上模板化的代码中。当你一直在运行std::string的代码时，你可以直接使用size_t。

【讨论】：

【解决方案2】：

我认为最好的方法是使用auto，这样您就可以自动符合函数返回的任何内容：

auto colon = name.find(":");

它避免了你描述的问题，而且要短得多。

正如 larsmans 在 cmets 中提到的，您可能希望将字符串索引存储在 struct 或任何没有可用于从中获取返回类型的变量中。这也是可行的：

struct StoreStringIndex {
    decltype(declval<std::string>().length()) length;
};

但比std::string::size_type 更复杂且不短。因此，对于存储内容，您可能希望使用类型的 size_type，但对于局部变量和内容，请使用 auto。

【讨论】：

不错的解决方案，但您在某种程度上回避了这个问题；假设您想将字符串索引存储在 struct 或 class 中。
或者大概是decltype(declval<std::string>().find(":")) posn_of_colon;？我想知道 C++ 是否是一种错误的语言，对于推断每种类型都非常顽固，当然除了在模板代码中你无法避免它。
@SteveJessop find 和 length 具有相同的返回类型，不是吗？那你就不需要把find(":")放在那里了。
是的（根据标准），并且（根据标准）该类型是size_t，因此您也可以使用它。它们都不是错的，但是由于您要推断类型，我会认为您想从与其使用相关的表达式中推断它，而不是从恰好具有相同的其他表达式类型。因此，如果该成员用于存储长度，则来自length()，如果用于存储查找结果的“索引或npos”，则来自find()。
好的，+1。我不知道declval。