在 IOStreams 库中使用 ignore(numeric_limits<streamsize>::max()) 是否可以处理任意大量流？答案

【问题标题】：Does using ignore(numeric_limits<streamsize>::max()) in the IOStreams library handle arbitrarily massive streams?在 IOStreams 库中使用 ignore(numeric_limits<streamsize>::max()) 是否可以处理任意大量流？
【发布时间】：2011-05-04 03:08:12
【问题描述】：

在 C++ 标准（第 27.6.1.3\24 节）中，对于 IOStreams 库中的 istream ignore() 函数，这意味着如果您为 numeric_limits::max() 的“n”提供参数，它将继续忽略字符直到找到分隔符为止，甚至超出实际流大小的最大值（即“n”参数被解释为无限）。

对于 gcc 实现，这确实看起来是 ignore() 已实现，但我仍然不清楚这是否是特定于实现的，或者是标准规定的。知道这一点的人可以确认这是由符合标准的 iostreams 库？

【问题讨论】：

你的意思是std::numeric_limits，确定吗？
如何为 istream 对象提供 numeric_limits::max() 个字符？
您正在使用哪个 istream 对象以及如何测试该条件？它不可能是cin，因为输入那么多字符大约需要20多个小时。我对您的测试方式而不是实际答案更感兴趣:)
@Eric：好吧，如果你在 32 位机器上编译（没有启用 LFS），那么在大于 4GB 的文件上执行此操作应该会达到限制。

标签： c++ iostream standards

【解决方案1】：

标准规定numeric_limits<streamsize>::max() 是一个特殊值，不会影响跳过的字符数。

效果：表现为未格式化的输入函数（如 27.7.2.3 第 1 段所述）。构建哨兵对象后，提取字符并丢弃它们。字符被提取，直到出现以下任何一种情况：
-- 如果n != numeric_limits<streamsize>::max() (18.3.2)，提取n个字符
-- 文件结束出现在输入序列上（在这种情况下，函数调用 setstate(eofbit)，可能会抛出 ios_base::failure (27.5.5.4)）；
-- traits::eq_int_type(traits::to_int_type(c), delim) 用于下一个可用的输入字符 c（在这种情况下 c 被提取）。

【讨论】：

是的，这正是我要说的 - 它指定了如果 n != numeric_limits::max() 会发生什么，但没有指定如果 n 确实会发生什么等于 numeric_limits::max();因此问题。
我对此的解释是，如果 n == numeric_limits::max()，则字符不计入限制。我们只是在寻找分隔符或文件结尾。另一方面，streamsize 将是我们拥有的最大整数之一，因此无论如何都很难达到这个值。
我认为应该这样理解：（1）有三个条件可以终止循环。 (2) 其中之一是已提取 n!=max 和 n 个字符。 (3) 其中之一是EOF。 (4) 其中之一是分隔符匹配。如果 n == max 则 (2) 永远不会发生，因此只有 2 个可能的终止条件。在标准说“如果 X，Y”的所有情况下，这意味着 Y 仅在 X 为真时适用。如果 X 为假，则 Y 无关紧要。
另一种学究式的逻辑解读是，当 n == max 时，第一个条件“如果 X 则 Y”是空洞的，因为 X 为假，因此提取立即停止。当标准以这种方式表达事物时，这不是的意思。无论如何，没有合理的阅读该段落告诉您“n 个字符已被提取”是当 n == max 时的终止条件。因此，我们必须得出结论，它不是。

【解决方案2】：

根据here：

istream&  istream::ignore ( streamsize n = 1, int delim = EOF );

提取和丢弃字符从输入序列中提取字符并丢弃它们。

当 n 个字符被提取并丢弃时，提取结束或当找到字符分隔符时，以先到者为准。在后一种情况下，delim 字符本身也会被提取。

在您的情况下，当 numeric_limits::max() 字符数达到时，满足第一个条件。

[每博]

但是，根据规范，仅当 n 不等于 numeric_limits<streamsize>::max() 时才应用上述情况。

【讨论】：

不，标准明确规定只有当 n != numeric_limits()::max 时才会出现这种情况。（看看博的回答中的摘录。）
永远不要相信 cplusplus 的话。它过于简化了，因为它认为对函数的作用进行一些描述总比不理解函数作用的准确描述要好。
@Steve，感谢您的建议。参考规范是我们解决此类问题的最后方法。