size_type 和 int 的区别

Question

#include <iostream>
#include <vector>
using namespace std;

int main()
{
    vector<double> student_marks(20);

    for (vector<double>::size_type i = 0; i < 20; i++)
    {
        cout << "Enter marks for student #" << i+1 
            << ": " << flush;
        cin >> student_marks[i];
    }
    return 0;
}

我在某处读到最好使用 size_type 代替 int 。它真的会对实施产生巨大影响吗？使用 size_type 有什么好处？

Answer 1

vector<double>::size_type 保证覆盖vector<double> 大小的所有可能值。 int 不是。

请注意vector<double>::size_type 通常与std::size_t 相同，因此通常使用后者就可以了。但是，自定义分配器可能会导致 size_type 与 std::size_t 不同的向量。

Answer 2

size_type 是一个无符号数字。这意味着它不能为负数。对于容器大小，这听起来可能是合乎逻辑的选择，但在现实生活中会产生很多问题。

例如，当您从另一个中减去一个 size_type 时，如果第二个操作数大于第一个操作数，则结果将默默地转换为一个巨大的正数：

std::vector<double>::size_type size1 = v1.size();
std::vector<double>::size_type size2 = v2.size();
if ((size1 - size2) > 5) // dangerous if v2 is bigger than v1!
{
    // ...
}

而且它经常使错误检查变得不可能：

void f(std::vector<double>::size_type size)
{
    if (size < 0)
    {
        // error handling will never be reached    
    }
}

f(-1); // no error handling

对于此类问题，您通常在代码中更喜欢（有符号）int 而不是unsigned，不幸的是，标准库容器将它们的大小表示为无符号数字。您通常希望尽快将 (static_cast) 大小转换为有符号数字。在您的示例中，保持无符号很好，因为它只是循环索引，并且首先转换为 int 会过度设计 IMO。

好消息是，您通常可以通过使用迭代器完全避免size_type：

for (std::vector<double>::const_iterator iter = v.begin(); iter != v.end(); ++iter)
{
    std::cout << *iter;
}

我邀请您看看 Scott Meyers 的 Signed and Unsigned Types in Interfaces。

最后，请注意，经验丰富的 C++ 程序员并未普遍认同这种观点。在网络上搜索有关此主题的过去讨论（旧的 Stackoverflow 问题、comp.lang.c++ Usenet 存档等）会发现不同的意见。

Answer 3

使用size_type 而不是size_t 的好处只是顺从。它取悦那些死记硬背、纯粹通过联想进行推理的人。他们确实喜欢看到别人和自己一样，并希望这被认为是“正确的”。

size_type 成员是容器大小类型的自定义点。它来自分配器模板参数。对于默认的标准分配器，它只是size_t 的同义词，即默认情况下，它们是相同的类型。

int 的问题与 ptrdiff_t（指针差异的结果类型）相反，问题在于 int 在 64 位系统上可能没有足够的范围来处理非常大的向量.

size_t 的问题在于它很容易导致在混合类型表达式中无意使用模运算。例如，表达式std::string( "Hi!" ).length() < -7 将始终产生true。因此，它是一个 bug 吸引器，所以ptrdiff_t，或者当你确定范围时只是简单的int，在客观上是非常可取的（尽管它可能会让上述人非常不高兴——仍然有一个非常强大的社交使用客观较差的解决方案的压力）。

在标准库中，无符号类型 size_t 用于历史原因。

特别是，在 16 位系统上，内存是一种非常有限的资源，必须使用每一个小技巧才能完全利用它——对于那些小系统，在那些日子里，这是非常值得的一些环绕错误等的风险。今天不是。