为什么读取时发现 eof 时会设置失败位？

Question

我读到 早于 。忽略 fstream 上的异常信息不多这一事实，我有以下问题：

可以使用 exceptions() 方法在文件流上启用异常。

ifstream stream;
stream.exceptions(ifstream::failbit | ifstream::badbit);
stream.open(filename.c_str(), ios::binary);

任何尝试打开不存在的文件、没有正确权限的文件或任何其他 I/O 问题都将导致异常。使用自信的编程风格非常好。该文件应该存在并且可读。如果不满足条件，我们就会得到一个例外。如果我不确定文件是否可以安全打开，我可以使用其他函数来测试它。

但现在假设我尝试读入缓冲区，如下所示：

char buffer[10];
stream.read(buffer, sizeof(buffer)); 

如果流在填充缓冲区之前检测到文件结尾，则流决定设置 failbit，并且如果满足以下条件，则会引发异常：他们被启用了。为什么？这有什么意义呢？我可以验证在读取后仅测试 eof()：

char buffer[10];
stream.read(buffer, sizeof(buffer));
if (stream.eof()) // or stream.gcount() != sizeof(buffer)
    // handle eof myself

这种设计选择阻止我在流上使用标准异常，并迫使我创建自己的权限或 I/O 错误异常处理。或者我错过了什么？还有出路吗？例如，我可以在执行此操作之前轻松测试是否可以读取流上的 sizeof(buffer) 字节吗？

Answer 1

故障位旨在允许流报告某些操作未能成功完成。这包括诸如无法打开文件、尝试读取不存在的数据以及尝试读取错误类型的数据等错误。

您所询问的特定情况在这里重印：

char buffer[10];
stream.read(buffer, sizeof(buffer)); 

您的问题是为什么在读取所有输入之前到达文件末尾时设置失败位。原因是，这意味着读取操作失败 - 您要求读取 10 个字符，但文件中没有足够多的字符。因此，操作未成功完成，并且流会发出失败位信号以让您知道这一点，即使将读取可用字符也是如此。

如果您想要执行读取操作，想要读取最多一定数量的字符，则可以使用readsome成员函数：

char buffer[10];
streamsize numRead = stream.readsome(buffer, sizeof(buffer)); 

该函数将读取最多字符数文件末尾，但与 read 不同，如果在读取字符之前到达文件末尾，则它不会设置失败位。换句话说，它表示“尝试读取这么多字符，但如果您不能读取，也不是错误。请告诉我您读取了多少字符。”这与 read 形成鲜明对比，后者表示“我想要精确这么多字符，如果你做不到，那就是一个错误。”

编辑：我忘记提及的一个重要细节是可以在不触发failbit的情况下设置eofbit。例如，假设我有一个文本文件，其中包含文本，

137

之后没有任何换行符或尾随空格。如果我写这段代码：

ifstream input("myfile.txt");

int value;
input >> value;

那么此时 input.eof() 将返回 true，因为当从文件中读取字符时，流会到达文件末尾，试图查看是否还有其他字符流中的字符。然而，input.fail() 将不会返回true，因为操作成功了——我们确实可以从文件中读取一个整数。

希望这有帮助！

Answer 2

直接使用底层缓冲区似乎可以解决问题：

char buffer[10];
streamsize num_read = stream.rdbuf()->sgetn(buffer, sizeof(buffer));

Answer 3

改进@absence的答案，它遵循一个方法readeof()，该方法执行与read()相同的操作，但不会在EOF上设置failbit。还测试了真实的读取失败，例如硬拔除 USB 记忆棒或网络共享访问中的链接丢失导致的传输中断。它已在使用 VS2010 和 VS2013 的 Windows 7 以及使用 gcc 4.8.1 的 Linux 上进行了测试。在 Linux 上，仅尝试过 USB 棒移除。

#include <iostream>
#include <fstream>
#include <stdexcept>

using namespace std;

streamsize readeof(istream &stream, char *buffer, streamsize count)
{
    if (count == 0 || stream.eof())
        return 0;

    streamsize offset = 0;
    streamsize reads;
    do
    {
        // This consistently fails on gcc (linux) 4.8.1 with failbit set on read
        // failure. This apparently never fails on VS2010 and VS2013 (Windows 7)
        reads = stream.rdbuf()->sgetn(buffer + offset, count);

        // This rarely sets failbit on VS2010 and VS2013 (Windows 7) on read
        // failure of the previous sgetn()
        (void)stream.rdstate();

        // On gcc (linux) 4.8.1 and VS2010/VS2013 (Windows 7) this consistently
        // sets eofbit when stream is EOF for the conseguences  of sgetn(). It
        // should also throw if exceptions are set, or return on the contrary,
        // and previous rdstate() restored a failbit on Windows. On Windows most
        // of the times it sets eofbit even on real read failure
        (void)stream.peek();

        if (stream.fail())
            throw runtime_error("Stream I/O error while reading");

        offset += reads;
        count -= reads;
    } while (count != 0 && !stream.eof());

    return offset;
}

#define BIGGER_BUFFER_SIZE 200000000

int main(int argc, char* argv[])
{
    ifstream stream;
    stream.exceptions(ifstream::badbit | ifstream::failbit);
    stream.open("<big file on usb stick>", ios::binary);

    char *buffer = new char[BIGGER_BUFFER_SIZE];

    streamsize reads = readeof(stream, buffer, BIGGER_BUFFER_SIZE);

    if (stream.eof())
        cout << "eof" << endl << flush;

    delete buffer;

    return 0;
}

底线：在 Linux 上，行为更加一致和有意义。如果在实际读取失败时启用异常，它将在 sgetn() 上抛出异常。相反，Windows 大多数时候会将读取失败视为 EOF。