基于CTT解决方案的更新函数:

#include <string>
#include <fstream>
#include <limits>
#include <string_view>
std::string readfile(const std::string_view path, bool binaryMode = true)
{
    std::ios::openmode openmode = std::ios::in;
    if(binaryMode)
    {
        openmode |= std::ios::binary;
    }
    std::ifstream ifs(path.data(), openmode);
    ifs.ignore(std::numeric_limits<std::streamsize>::max());
    std::string data(ifs.gcount(), 0);
    ifs.seekg(0);
    ifs.read(data.data(), data.size());
    return data;
}

有两个重要的区别:

Tellg()不保证返回自文件开始以来的字节偏移量。相反，正如Puzomor Croatia所指出的，它更像是一个可以在fstream调用中使用的令牌。但是Gcount()会返回上次提取的未格式化字节数。因此，我们打开文件，使用ignore()提取并丢弃其所有内容，以获得文件的大小，并基于此构造输出字符串。

其次，我们通过直接写入字符串来避免必须将文件的数据从std::vector<char>复制到std::string。

就性能而言，这应该是绝对最快的，提前分配适当大小的字符串并调用read()一次。有趣的是，在gcc上使用ignore()和countg()而不是ate和tellg()会一点一点地编译成几乎相同的东西。

这样的事情应该不会太糟糕:

void slurp(std::string& data, const std::string& filename, bool is_binary)
{
    std::ios_base::openmode openmode = ios::ate | ios::in;
    if (is_binary)
        openmode |= ios::binary;
    ifstream file(filename.c_str(), openmode);
    data.clear();
    data.reserve(file.tellg());
    file.seekg(0, ios::beg);
    data.append(istreambuf_iterator<char>(file.rdbuf()), 
                istreambuf_iterator<char>());
}

这样做的好处是，我们先做了预留，这样我们就不必在读入时增加字符串。缺点是我们一个字符一个字符地做。更聪明的版本可以抓取整个read buf，然后调用下流。

该解决方案将错误检查添加到基于rdbuf()的方法中。

std::string file_to_string(const std::string& file_name)
{
    std::ifstream file_stream{file_name};

    if (file_stream.fail())
    {
        // Error opening file.
    }

    std::ostringstream str_stream{};
    file_stream >> str_stream.rdbuf();  // NOT str_stream << file_stream.rdbuf()

    if (file_stream.fail() && !file_stream.eof())
    {
        // Error reading file.
    }

    return str_stream.str();
}

I'm adding this answer because adding error-checking to the original method is not as trivial as you'd expect. The original method uses stringstream's insertion operator (str_stream << file_stream.rdbuf()). The problem is that this sets the stringstream's failbit when no characters are inserted. That can be due to an error or it can be due to the file being empty. If you check for failures by inspecting the failbit, you'll encounter a false positive when you read an empty file. How do you disambiguate legitimate failure to insert any characters and "failure" to insert any characters because the file is empty?

您可能会认为显式地检查空文件，但这是更多的代码和相关的错误检查。

检查失败条件str_stream.fail() && !str_stream.eof()不工作，因为插入操作没有设置eofbit(在ostringstream或ifstream上)。

所以，解决办法就是改变操作。不要使用ostringstream的插入操作符(<<)，而是使用ifstream的提取操作符(>>)，它确实设置了eofbit。然后检查失败条件file_stream.fail() && !file_stream.eof()。

重要的是，当file_stream >> str_stream.rdbuf()遇到合法的失败时，它不应该设置eofbit(根据我对规范的理解)。这意味着上述检查足以检测出合法的故障。

由于这似乎是一个广泛使用的实用程序，我的方法是搜索并选择已经可用的库，而不是手工制作的解决方案，特别是如果boost库已经在您的项目中链接(链接器标志-lboost_system -lboost_filesystem)。在这里(以及旧的boost版本)，boost提供了一个load_string_file实用程序:

#include <iostream>
#include <string>
#include <boost/filesystem/string_file.hpp>

int main() {
    std::string result;
    boost::filesystem::load_string_file("aFileName.xyz", result);
    std::cout << result.size() << std::endl;
}

作为一个优点，这个函数不寻求整个文件来确定大小，而是在内部使用stat()。然而，一个可能可以忽略不计的缺点是，在检查源代码时可以很容易地推断出:字符串不必要地用'\0'字符来调整大小，而'\0'字符是由文件内容重写的。

#include <string>
#include <sstream>

using namespace std;

string GetStreamAsString(const istream& in)
{
    stringstream out;
    out << in.rdbuf();
    return out.str();
}

string GetFileAsString(static string& filePath)
{
    ifstream stream;
    try
    {
        // Set to throw on failure
        stream.exceptions(fstream::failbit | fstream::badbit);
        stream.open(filePath);
    }
    catch (system_error& error)
    {
        cerr << "Failed to open '" << filePath << "'\n" << error.code().message() << endl;
        return "Open fail";
    }

    return GetStreamAsString(stream);
}

用法:

const string logAsString = GetFileAsString(logFilePath);

最短的变体:Live On Coliru

std::string str(std::istreambuf_iterator<char>{ifs}, {});

它需要头文件<iterator>。

有一些报告说，这种方法比预先分配字符串和使用std::istream::read要慢。然而，在现代的编译器上，这种情况似乎不再存在，尽管各种方法的相对性能似乎高度依赖于编译器。