How do I read an entire file into a std::string in C++?

Question

How do I read a file into a std::string, i.e., read the whole file at once?

Text or binary mode should be specified by the caller. The solution should be standard-compliant, portable and efficient. It should not needlessly copy the string's data, and it should avoid reallocations of memory while reading the string.

One way to do this would be to stat the filesize, resize the std::string and fread() into the std::string's const_cast<char*>()'ed data(). This requires the std::string's data to be contiguous which is not required by the standard, but it appears to be the case for all known implementations. What is worse, if the file is read in text mode, the std::string's size may not equal the file's size.

A fully correct, standard-compliant and portable solutions could be constructed using std::ifstream's rdbuf() into a std::ostringstream and from there into a std::string. However, this could copy the string data and/or needlessly reallocate memory.

• Are all relevant standard library implementations smart enough to avoid all unnecessary overhead?
• Is there another way to do it?
• Did I miss some hidden Boost function that already provides the desired functionality?

void slurp(std::string& data, bool is_binary)

Millstream

Note that you still have some things underspecified. For example, what's the character encoding of the file? Will you attempt to auto-detect (which works only in a few specific cases)? Will you honor e.g. XML headers telling you the encoding of the file? Also there's no such thing as "text mode" or "binary mode" -- are you thinking FTP? – Cwm

Text and binary mode are MSDOS & Windows specific hacks that try to get around the fact that newlines are represented by two characters in Windows (CR/LF). In text mode, they are treated as one character ('\n'). – Swope

Usually such things are treated by routines that break strings into lines rather than routines that read data from files. That is, in every environment I've programmed in there's some kind of readAsLines() or breakIntoLines() that is intelligent about such things. – Cwm

Although not (quite) an exactly duplicate, this is closely related to: how to pre-allocate memory for a std::string object? (which, contrary to Konrad's statement above, included code to do this, reading the file directly into the destination, without doing an extra copy). – Doloresdolorimetry

"contiguous is not required by the standard" - yes it is, in a roundabout way. As soon as you use op[] on the string, it must be coalesced into a contiguous writable buffer, so it is guaranteed safe to write to &str[0] if you .resize() large enough first. And in C++11, string is simply always contiguous. – Sandstrom

Related link: How to read a file in C++? -- benchmarks and discusses the various approaches. And yes, rdbuf (the one in the accepted answer) isn't the fastest, read is. – Floe

All of these solutions will lead to mal-formed strings if your file-encoding/interpratation is incorrect. I was having a really weird issue when serializing a JSON file into a string until I manually converted it to UTF-8; I was only ever getting the first character no matter what solution I tried! Just a gotcha to watch out for! :) – Hejaz

Answer 1

One way is to flush the stream buffer into a separate memory stream, and then convert that to std::string (error handling omitted):

std::string slurp(std::ifstream& in) {
    std::ostringstream sstr;
    sstr << in.rdbuf();
    return sstr.str();
}

This is nicely concise. However, as noted in the question this performs a redundant copy and unfortunately there is fundamentally no way of eliding this copy.

The only real solution that avoids redundant copies is to do the reading manually in a loop, unfortunately. Since C++ now has guaranteed contiguous strings, one could write the following (≥C++17, error handling included):

auto read_file(std::string_view path) -> std::string {
    constexpr auto read_size = std::size_t(4096);
    auto stream = std::ifstream(path.data());
    stream.exceptions(std::ios_base::badbit);

    if (not stream) {
        throw std::ios_base::failure("file does not exist");
    }
    
    auto out = std::string();
    auto buf = std::string(read_size, '\0');
    while (stream.read(& buf[0], read_size)) {
        out.append(buf, 0, stream.gcount());
    }
    out.append(buf, 0, stream.gcount());
    return out;
}

Requirement

What's the point of making it a oneliner? I'd always opt for legible code. As a self-professed VB.Net enthusiast (IIRC) I think you should understand the sentiment? – Pinky

@sehe: I would expect any halfway-competent C++ coder to readily understand that one-liner. It's pretty tame compared to other stuff being around. – Hooey

@Hooey Well, the more legible version is ~30% shorter, lacks a cast and is otherwise equivalent. My question therefore stands: "What's the point of making it a oneliner?" – Pinky

@Pinky I never said that I’d use the oneliner in real code. It was more to show that it’s possible to do it in a single expression. – Requirement

@KonradRudolph Wokay. Glad to know that. I'm just a bit flurbled that you mentioned it then. Anyways, I'll upvote your other answer (??!) then for gimmick-ness :) – Pinky

I know this is very old, but I just did some profiling of several methods and I found that getting the file size and calling in.read into a buffer preallocated to the correct size is much faster than this. Around 10x. I'm using VS2012 and testing with a 100mb file. – Musick

@Dave Minimally faster – maybe. 10x? This hints at a defect in the standard library implementation. – Requirement

Just wanted to add, that for someone learning C++, this is hard to understand at first glance. – Beggs

@John That’s why you put it into its proper function. Most nontrivial code is hard to understand for beginners, if that were an argument against using such code, we’d never get any work done. – Requirement

note: this method reads the file into the stringstream's buffer, then copies that whole buffer into the string. I.e. requiring twice as much memory as some of the other options. (There is no way to move the buffer). For a large file this would be a significant penalty, perhaps even causing an allocation failure . – Buffon

@Buffon Good point, no idea how this slipped under the radar for so long. – Requirement

@Pinky For what it's worth, I place a huge premium on concision. I don't want to introduce a new function just for the sake of what in my current program is a minor piece of functionality involving reading one line from a file for an unimportant purpose. Just the requirement of adding a function to do this would cause me to not even bother reading the line. Having one line of code to do it, in my case, allows the single line of code not to stand out, so I'm doing it that way happily! – Elysia

@DanNissenbaum You're confusing something. Conciseness is indeed important in programming, but the proper way to achieve it is to decompose the problem into parts and encapsulate those into independent units (functions, classes, etc). Adding functions doesn't detract from conciseness; quite the contrary. – Requirement

@KonradRudolph I hear you. As the years pass I have moved away from adding functions and classes for one-time use, because their very presence gives weight to their importance. It's nice to be able to look at code and see a simple, small set of functions and classes representing the core functionality. I have taken to using the 'rule of three' - if a short code block is only used once or even twice, the benefit of not having a function can outweigh the benefit of encapsulation. Only by the time it reaches a third use will I sometimes be swayed to encapsulate it. This 'file slurp' fits. – Elysia

@DanNissenbaum that's why lambdas were introduced :) – Champollion

I think this solution only works if you want to read the file in binary mode. If you want to read it in text mode, istream_iterator is the cleanest way. Is that correct? – Fluoroscope

This way is slow (because std::stringstream is slow). – Igniter

@Igniter Slow compared to what? Reading into a string stream is blazing fast. The problem is that the string data cannot be moved out of the stream, it needs to be copied out. – Requirement

Why not dynamic_cast instead of static_cast? Aren't we just downcasting? – Inoue

@Ayxan Using a dynamic_cast only really makes sense if you don't know whether the cast will succeed, and test the return value (or catch the potential bad_cast). However, we know that the cast succeeds here so there's no need to hedge our bets. Ideally weʼd use a cast that only performs downcasting, and at the same time asserts that the cast will succeed. Alas, such a cast does not exist in C++. – Requirement

Will this method trigger memory reallocation for many times ? – Celle

this solution is short, but confusing. rdbuf() returns filebuf*. How does putting pointer to rdbuf makes stringstream to read file content? I would prefer more verbose, but more clear code than this magic. – Coot

@Coot It’s not magic, but it does require knowing how the relevant members work, which is documented. What you seem to be missing is overload (9) on this page: en.cppreference.com/w/cpp/io/basic_ostream/operator_ltlt – Requirement

"This is nicely concise." <- Maybe, but it will fail silently, so the conciseness is misleading. – Watters

@Watters Yes, hence the second part of the answer, which is a proper solution that’s both efficient and has a proper failure mode. – Requirement

@KonradRudolph: ... but your answer says the second solution is for avoiding redundant copying, not for avoiding silent failure. Would you consider editing? – Watters

@Watters Sure, edited. – Requirement

Un-downvoted, but I still feel it's a bit of a cheat to omit the error handling and extol the conciseness. – Watters

@Watters I think you’ve missed how ancient this question and the answers are. From the get-go this was a bit of light-hearted fun, and not intended as a proper, production-ready solution (who uses such a “slurp file” function in a proper piece of software anyway — excluding one-off scripts?). And you’re applying a bit of a double-standard: none of the other original answers performed error handling. Meanwhile, my original solution does allow error handling (by the caller!), and I went back later to add a proper answer to the answer, leaving the historical answer in place for reference. – Requirement

Surely repeated appending to a string will result in resizing it a few times, yeah? That hardly sounds like "avoiding redundant copies" to me. – Patman

@KarlKnechtel The C++ standard does not mandate a complexity but typical implementations use a doubling-reserve strategy so that the amortised time complexity for appending is constant, and the expected number of resizes is logarithmic. This is really the best we can do without guessing the resulting string size, which I'm not a fan of (but yes, we could do this using the pre-read file size as a proxy). – Requirement

Just my 2 cents: why making the second sample so hard to read for beginners with autos everywhere even if it's completely unnecessary because longer? – Passade

@Passade Actually using auto everywhere makes C++ code easier to read, because it makes variable declaration syntax uniform. Without auto, C++ variable declaration syntax is notoriously complex and ambiguous, and leads to actual bugs. That's the reason I use auto everywhere when writing C++ code. This style is called AA ("always auto") and is recommended by several C++ experts. – Requirement

read_file reports nothing if the file doesn't exist? – Papillose

@Papillose Excellent point, thanks. I had overlooked that. Fixed now. – Requirement

Answer 2

The shortest variant: Live On Coliru

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

It requires the header <iterator>.

There were some reports that this method is slower than preallocating the string and using std::istream::read. However, on a modern compiler with optimisations enabled this no longer seems to be the case, though the relative performance of various methods seems to be highly compiler dependent.

Requirement

Could you exapnd on this answer. How efficent is it, does it read a file a char at a time, anyway to preallocate the stirng memory? – Dung

@Buffon The way I read that comparison, this method is slower than the pure C++ reading-into-a-preallocated-buffer method. – Requirement

You're right, it's a case of the title being under the code sample, rather than above it :) – Buffon

Will this method trigger memory reallocation for many times ? – Celle

@coincheung Unfortunately yes. If you want to avoid memory allocations you need to manually buffer the reading. C++ IO streams are pretty crap. – Requirement

@KonradRudolph Thanks, I noticed there is another way like this: stringstream ss; ifs >> ss.rdbuf(); str = ss.str();, will this method also trigger many memory reallocations please ? – Celle

@coincheung This should avoid repeat allocations but, in practice, it stupidly doesn’t. The “canonical” way of reading a whole file in C++17 is gist.github.com/klmr/849cbb0c6e872dff0fdcc54787a66103. Unfortunately very verbose. – Requirement

Answer 3

See this answer on a similar question.

For your convenience, I'm reposting CTT's solution:

string readFile2(const string &fileName)
{
    ifstream ifs(fileName.c_str(), ios::in | ios::binary | ios::ate);

    ifstream::pos_type fileSize = ifs.tellg();
    ifs.seekg(0, ios::beg);

    vector<char> bytes(fileSize);
    ifs.read(bytes.data(), fileSize);

    return string(bytes.data(), fileSize);
}

This solution resulted in about 20% faster execution times than the other answers presented here, when taking the average of 100 runs against the text of Moby Dick (1.3M). Not bad for a portable C++ solution, I would like to see the results of mmap'ing the file ;)

Taryntaryne

related: time performance comparison of various methods: Reading in an entire file at once in C++ – Ocam

Up until today, I have never witnessed tellg() reporting non-filesize results. Took me hours to find the source of the bug. Please do not use tellg() to get the file size. #22985456 – Cetology

shouldn't you call ifs.seekg(0, ios::end) before tellg? just after opening a file reading pointer is at the beginning and so tellg returns zero – Sleeve

also you need to check for empty files as you'll dereference nullptr by &bytes[0] – Sleeve

ok, I've missed ios::ate, so I think a version with explicit moving to the end would be more readable – Sleeve

Note that this solution only works for binary mode; whereas the OP asked for a solution for both binary and text mode. – Buffon

Since C++11 strings are guaranteed to have contiguous storage, so you can directly use a string instead of the vector and thus skip the vector to string copy. – Pinkney

That solution is not portable, as the result of .tellg() is not guaranteed to return the size of the file. (and in practice, some systems do not). – Meliamelic

@Meliamelic can you point to a system or an implementation of C++ that is known not to return the offset in bytes? – Taryntaryne

@paxos1977> stating on which systems your program is defined to be correct is up to you. As is, it relies on guarantees that are not provided by C++, and as such is wrong. If it works on a known set of implementations that do provide such guarantees (as in: documented as guarantees, not mere "it happens to look okay today on that version I have around"), then make that explicit, otherwise it's misleading. – Meliamelic

@Meliamelic I agree the standard doesn't guarantee this is portable to all implementations b/c it depends on implementation specific behavior... however, it's only broken on some unknown, unnamed, theoretical C++ implementation that uses tokens instead of a byte offset for tellg(). You can't name an implementation where this wouldn't work and neither can I, so I think this is "portable enough". – Taryntaryne

Perfect reasoning for building brittle codebases that break unexpectedly because whatever behavior I observed one day was "portable enough". Until someone changed it. It's not like we have a history of over and over again. — Proper engineering is done by building upon guarantees, not probing whatever seems to work now and hope for the best. Thus: this code is only sound engineering one implementations where its assumptions are guaranteed. [note: I did not talk about whether it happens to work or not today, that is irrelevant] – Meliamelic

…Otherwise it's no better than a use-after-delete or a dangling reference but "it never crashed in any place where I ran it, so that's portable enough". – Meliamelic

@Meliamelic I wouldn't put "implementation defined behavior" in the same class of bug as "use after free" or "dangling reference". Use after free and dangling reference are always broken everywhere. You're pushing hyperbole. – Taryntaryne

@Meliamelic "Proper engineering is done by building upon guarantees, not probing whatever seems to work now and hope for the best" spoken like a student who's never actually written or maintained a real production code base. In the real world, you always know exactly what platforms you're targeting and with which compilers. If depending on implementation defined behavior gets you better performance, then you do it and note the problem in the commit log and comments in the code. If performance doesn't matter, then you would implement using the most readable code not the fastest. – Taryntaryne

…or spoken as a seasoned professional who has seen so many "this should never happen" bugs while working on long-lived codebases they learnt that "this should never happen", "we will never target another platform", "the compiler will never get a new version" are not a thing in a real production codebase for a company that outlives its initial product launch. So when you end up relying on those, the bare minimum is to clearly flag it, and have a unit test for it. – Meliamelic

Answer 4

If you have C++17 (std::filesystem), there is also this way (which gets the file's size through std::filesystem::file_size instead of seekg and tellg):

#include <filesystem>
#include <fstream>
#include <string>

namespace fs = std::filesystem;

std::string readFile(fs::path path)
{
    // Open the stream to 'lock' the file.
    std::ifstream f(path, std::ios::in | std::ios::binary);

    // Obtain the size of the file.
    const auto sz = fs::file_size(path);

    // Create a buffer.
    std::string result(sz, '\0');

    // Read the whole file into the buffer.
    f.read(result.data(), sz);

    return result;
}

Note: you may need to use <experimental/filesystem> and std::experimental::filesystem if your standard library doesn't yet fully support C++17. You might also need to replace result.data() with &result[0] if it doesn't support non-const std::basic_string data.

Boeotian

This may cause undefined behaviour; opening the file in text mode yields a different stream than the disk file on some operating systems. – Buffon

Originally developed as boost::filesystem so you can also use boost if you don't have c++17 – Stephens

Opening a file with one API and getting its size with another seems to be asking for inconsistency and race conditions. – Etana

What's the advantage of using std::filesystem::file_size instead of seekg and tellg? – Stomachic

Answer 5

Use

#include <iostream>
#include <sstream>
#include <fstream>

int main()
{
  std::ifstream input("file.txt");
  std::stringstream sstr;

  while(input >> sstr.rdbuf());

  std::cout << sstr.str() << std::endl;
}

or something very close. I don't have a stdlib reference open to double-check myself.

Yes, I understand I didn't write the slurp function as asked.

Yacano

This looks nice, but it doesn't compile. Changes to make it compile reduce it to other answers on this page. ideone.com/EyhfWm – Bidwell

Why the while loop? – Katzenjammer

Agreed. When operator>> reads into a std::basic_streambuf, it will consume (what's left of) the input stream, so the loop is unnecessary. – Flirtation

Answer 6

I do not have enough reputation to comment directly on responses using tellg().

Please be aware that tellg() can return -1 on error. If you're passing the result of tellg() as an allocation parameter, you should sanity check the result first.

An example of the problem:

...
std::streamsize size = file.tellg();
std::vector<char> buffer(size);
...

In the above example, if tellg() encounters an error it will return -1. Implicit casting between signed (ie the result of tellg()) and unsigned (ie the arg to the vector<char> constructor) will result in a your vector erroneously allocating a very large number of bytes. (Probably 4294967295 bytes, or 4GB.)

Modifying paxos1977's answer to account for the above:

string readFile2(const string &fileName)
{
    ifstream ifs(fileName.c_str(), ios::in | ios::binary | ios::ate);

    ifstream::pos_type fileSize = ifs.tellg();
    if (fileSize < 0)                             <--- ADDED
        return std::string();                     <--- ADDED

    ifs.seekg(0, ios::beg);

    vector<char> bytes(fileSize);
    ifs.read(&bytes[0], fileSize);

    return string(&bytes[0], fileSize);
}

Adaurd

Not only that, but tellg() does not return the size but a token. Many systems use a byte offset as a token, but this is not guaranteed, and some systems do not. Check this answer for an example. – Meliamelic

Answer 7

Since this seems like a widely used utility, my approach would be to search for and to prefer already available libraries to hand made solutions, especially if boost libraries are already linked(linker flags -lboost_system -lboost_filesystem) in your project. Here (and older boost versions too), boost provides a load_string_file utility:

#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;
}

As an advantage, this function doesn't seek an entire file to determine the size, instead uses stat() internally. As a possibly negligible disadvantage though, one could easily infer upon inspection of the source code: string is unnecessarily resized with '\0' character which are rewritten by the file contents.

Pontefract

Answer 8

This solution adds error checking to the rdbuf()-based method.

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?

You might think to explicitly check for an empty file, but that's more code and associated error checking.

Checking for the failure condition str_stream.fail() && !str_stream.eof() doesn't work, because the insertion operation doesn't set the eofbit (on the ostringstream nor the ifstream).

So, the solution is to change the operation. Instead of using ostringstream's insertion operator (<<), use ifstream's extraction operator (>>), which does set the eofbit. Then check for the failiure condition file_stream.fail() && !file_stream.eof().

Importantly, when file_stream >> str_stream.rdbuf() encounters a legitimate failure, it shouldn't ever set eofbit (according to my understanding of the specification). That means the above check is sufficient to detect legitimate failures.

Dehumanize

Answer 9

Something like this shouldn't be too bad:

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>());
}

The advantage here is that we do the reserve first so we won't have to grow the string as we read things in. The disadvantage is that we do it char by char. A smarter version could grab the whole read buf and then call underflow.

Briton

You should checkout the version of this code that uses std::vector for the initial read rather than a string. Much much faster. – Taryntaryne

Answer 10

Here's a version using the new filesystem library with reasonably robust error checking:

#include <cstdint>
#include <exception>
#include <filesystem>
#include <fstream>
#include <sstream>
#include <string>

namespace fs = std::filesystem;

std::string loadFile(const char *const name);
std::string loadFile(const std::string &name);

std::string loadFile(const char *const name) {
  fs::path filepath(fs::absolute(fs::path(name)));

  std::uintmax_t fsize;

  if (fs::exists(filepath)) {
    fsize = fs::file_size(filepath);
  } else {
    throw(std::invalid_argument("File not found: " + filepath.string()));
  }

  std::ifstream infile;
  infile.exceptions(std::ifstream::failbit | std::ifstream::badbit);
  try {
    infile.open(filepath.c_str(), std::ios::in | std::ifstream::binary);
  } catch (...) {
    std::throw_with_nested(std::runtime_error("Can't open input file " + filepath.string()));
  }

  std::string fileStr;

  try {
    fileStr.resize(fsize);
  } catch (...) {
    std::stringstream err;
    err << "Can't resize to " << fsize << " bytes";
    std::throw_with_nested(std::runtime_error(err.str()));
  }

  infile.read(fileStr.data(), fsize);
  infile.close();

  return fileStr;
}

std::string loadFile(const std::string &name) { return loadFile(name.c_str()); };

Beluga

infile.open can also accept std::string without converting with .c_str() – Grassland

filepath isn't a std::string, it's a std::filesystem::path. Turns out std::ifstream::open can accept one of those as well. – Beluga

@DavidG, std::filesystem::path is implicitly convertible to std::string – Leveroni

According to cppreference.com, the ::open member function on std::ifstream that accepts std::filesystem::path operates as if the ::c_str() method were called on the path. The underlying ::value_type of paths is char under POSIX. – Beluga

Answer 11

I know this is a positively ancient question with a plethora of answers, but not one of them mentions what I would have considered the most obvious way to do this. Yes, I know this is C++, and using libc is evil and wrong or whatever, but nuts to that. Using libc is fine, especially for such a simple thing as this.

Essentially: just open the file, get it's size (not necessarily in that order), and read it.

#include <string>
#include <cstdio>
#include <cstdlib>
#include <cstring>
#include <sys/stat.h>

static constexpr char filename[] = "foo.bar";

int main(void)
{
    FILE *fp = ::fopen(filename, "rb");
    if (!fp) {
        ::perror("fopen");
        ::exit(1);
    }

    // Stat isn't strictly part of the standard C library, 
    // but it's in every libc I've ever seen for a hosted system.
    struct stat st;
    if (::fstat(::fileno(fp), &st) == (-1)) {
        ::perror("fstat");
        ::exit(1);
    }

    // You could simply allocate a buffer here and use std::string_view, or
    // even allocate a buffer and copy it to a std::string. Creating a
    // std::string and setting its size is simplest, but will pointlessly
    // initialize the buffer to 0. You can't win sometimes.
    std::string str;
    str.reserve(st.st_size + 1U);
    str.resize(st.st_size);
    ::fread(str.data(), 1, st.st_size, fp);
    str[st.st_size] = '\0';
    ::fclose(fp);
}

This doesn't really seem worse than some of the other solutions, in addition to being (in practice) completely portable. One could also throw an exception instead of exiting immediately, of course. It seriously irritates me that resizing the std::string always 0 initializes it, but it can't be helped.

PLEASE NOTE that this is only going to work as written for C++17 and later. Earlier versions (ought to) disallow editing std::string::data(). If working with an earlier version consider replacing str.data() with &str[0].

Disguise

What's the std::string? – Watters

@Watters I figured the op would be able make one themselves from the C string. On reflection you're probably right, the question specifically asked how to read it into a std::string. Updated. – Disguise

Answer 12

You can use the 'std::getline' function, and specify 'eof' as the delimiter. The resulting code is a little bit obscure though:

std::string data;
std::ifstream in( "test.txt" );
std::getline( in, data, std::string::traits_type::to_char_type( 
                  std::string::traits_type::eof() ) );

Swedenborgianism

I just tested this, it appears to be much slower than getting the file size and calling read for the whole file size into a buffer. On the order of 12x slower. – Musick

This will only work, as long as there are no "eof" (e.g. 0x00, 0xff, ...) characters in your file. If there are, you will only read part of the file. – Verada

Answer 13

For performance I haven't found anything faster than the code below.

std::string readAllText(std::string const &path)
{
    assert(path.c_str() != NULL);
    FILE *stream = fopen(path.c_str(), "r");
    assert(stream != NULL);
    fseek(stream, 0, SEEK_END);
    long stream_size = ftell(stream);
    fseek(stream, 0, SEEK_SET);
    void *buffer = malloc(stream_size);
    fread(buffer, stream_size, 1, stream);
    assert(ferror(stream) == 0);
    fclose(stream);
    std::string text((const char *)buffer, stream_size);
    assert(buffer != NULL);
    free((void *)buffer);
    return text;
}

Gleda

This can certainly be sped up faster. For one thing, use rb (binary) mode instead of r (text) mode. And get rid of malloc(), you don't need it. You can resize() a std::string and then fread() directly into its memory buffer. No need to malloc() a buffer and then copy it into a std::string. – Flirtation

@RemyLebeau resize() does pointlessly 0 initialize the memory though. Still faster than a full copy, of course, but pointless all the same. As to this post: using an assertion to check the result of fopen() is straight up Evil and Wrong. It must ALWAYS be checked, not only in a debug build. With this implementation a simple typo would cause undefined behavior (sure, in practice a segfault, but that's hardly the point). – Disguise

Answer 14

Pulling info from several places... This should be the fastest and best way:

#include <filesystem>
#include <fstream>
#include <string>

//Returns true if successful.
bool readInFile(std::string pathString)
{
  //Make sure the file exists and is an actual file.
  if (!std::filesystem::is_regular_file(pathString))
  {
    return false;
  }
  //Convert relative path to absolute path.
  pathString = std::filesystem::weakly_canonical(pathString);
  //Open the file for reading (binary is fastest).
  std::wifstream in(pathString, std::ios::binary);
  //Make sure the file opened.
  if (!in)
  {
    return false;
  }
  //Wide string to store the file's contents.
  std::wstring fileContents;
  //Jump to the end of the file to determine the file size.
  in.seekg(0, std::ios::end);
  //Resize the wide string to be able to fit the entire file (Note: Do not use reserve()!).
  fileContents.resize(in.tellg());
  //Go back to the beginning of the file to start reading.
  in.seekg(0, std::ios::beg);
  //Read the entire file's contents into the wide string.
  in.read(fileContents.data(), fileContents.size());
  //Close the file.
  in.close();
  //Do whatever you want with the file contents.
  std::wcout << fileContents << L" " << fileContents.size();
  return true;
}

This reads in wide characters into a std::wstring, but you can easily adapt if you just want regular characters and a std::string.

Anaxagoras

Answer 15

#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);
}

usage:

const string logAsString = GetFileAsString(logFilePath);

Sightseeing

Answer 16

An updated function which builds upon CTT's solution:

#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;
}

There are two important differences:

tellg() is not guaranteed to return the offset in bytes since the beginning of the file. Instead, as Puzomor Croatia pointed out, it's more of a token which can be used within the fstream calls. gcount() however does return the amount of unformatted bytes last extracted. We therefore open the file, extract and discard all of its contents with ignore() to get the size of the file, and construct the output string based on that.

Secondly, we avoid having to copy the data of the file from a std::vector<char> to a std::string by writing to the string directly.

In terms of performance, this should be the absolute fastest, allocating the appropriate sized string ahead of time and calling read() once. As an interesting fact, using ignore() and countg() instead of ate and tellg() on gcc compiles down to almost the same thing, bit by bit.

Machmeter

This code does not work, I'm getting empty string. I think you wanted ifs.seekg(0) instead of ifs.clear() (then it works). – Armbrecht

std::string::data() returns const char* before C++17. – Watters

Answer 17

this is the function i use, and when dealing with large files (1GB+) for some reason std::ifstream::read() is much faster than std::ifstream::rdbuf() when you know the filesize, so the whole "check filesize first" thing is actually a speed optimization

#include <string>
#include <fstream>
#include <sstream>
std::string file_get_contents(const std::string &$filename)
{
    std::ifstream file($filename, std::ifstream::binary);
    file.exceptions(std::ifstream::failbit | std::ifstream::badbit);
    file.seekg(0, std::istream::end);
    const std::streampos ssize = file.tellg();
    if (ssize < 0)
    {
        // can't get size for some reason, fallback to slower "just read everything"
        // because i dont trust that we could seek back/fourth in the original stream,
        // im creating a new stream.
        std::ifstream file($filename, std::ifstream::binary);
        file.exceptions(std::ifstream::failbit | std::ifstream::badbit);
        std::ostringstream ss;
        ss << file.rdbuf();
        return ss.str();
    }
    file.seekg(0, std::istream::beg);
    std::string result(size_t(ssize), 0);
    file.read(&result[0], std::streamsize(ssize));
    return result;
}

Korman

std::string result(size_t(ssize), 0); fills the string with the char 0 (null or \0), this may be considered "unnecessary overhead", as per the OP's question – Corm

@MarcheRemi indeed, its basically like using calloc() when all you need is malloc(). that said, creating a string of uninitialized bytes is really hard - i think you can supply a custom allocator to actually make it happen, but seems nobody has figured out exactly how yet. – Korman

What's with the dollar sign? – Watters

@Watters that was... inherited from php's api, it's a (incomplete) port of php's file_get_contents – Korman

Answer 18

You can use the rst C++ library that I developed to do that:

#include "rst/files/file_utils.h"

std::filesystem::path path = ...;  // Path to a file.
rst::StatusOr<std::string> content = rst::ReadFile(path);
if (content.err()) {
  // Handle error.
}

std::cout << *content << ", " << content->size() << std::endl;

Smackdab

Answer 19

#include <string>
#include <fstream>

int main()
{
    std::string fileLocation = "C:\\Users\\User\\Desktop\\file.txt";
    std::ifstream file(fileLocation, std::ios::in | std::ios::binary);

    std::string data;

    if(file.is_open())
    {
        std::getline(file, data, '\0');

        file.close();
    }
}

Jerald

Seems to be a variant of Martin Cote's 2008 answer, which uses EOF? (And the same caveats apply as those written in the comments on that answer.) Please also try to provide more information than a block of code, see How do I write a good answer?. – Powwow

Answer 20

For a small to medium sized file I use these methods which are quite fast. The one returning string can be used to "convert" the byte array to string.

auto read_file_bytes(std::string_view filepath) -> std::vector<std::byte> {
    std::ifstream ifs(filepath.data(), std::ios::binary | std::ios::ate);

    if (!ifs)
        throw std::ios_base::failure("File does not exist");

    auto end = ifs.tellg();
    ifs.seekg(0, std::ios::beg);

    auto size = std::size_t(end - ifs.tellg());

    if (size == 0) // avoid undefined behavior
        return {};

    std::vector<std::byte> buffer(size);

    if (!ifs.read((char *) buffer.data(), buffer.size()))
        throw std::ios_base::failure("Read error");

    return buffer;
}

auto read_file_string(std::string_view filepath) -> std::string {
    auto bytes = read_file_bytes(filepath);
    return std::string(reinterpret_cast<char *>(bytes.begin().base()), bytes.size());
}

Lentil

bytes.begin().base() should be bytes.data() instead. You could alternatively use the std::string constructor that accepts iterators, eg: return std::string(bytes.begin(), bytes.end());. But, I would suggest re-writing read_file_string() to not rely on read_file_bytes() at all. You should just use the same reading logic but read the file data directly into the target std::string rather than into an intermediate std::vector that is then converted into a std::string. That would be more efficient, and won't need to store two copies of the file data in memory, if only briefly. – Flirtation

Answer 21

Never write into the std::string's const char * buffer. Never ever! Doing so is a massive mistake.

Reserve() space for the whole string in your std::string, read chunks from your file of reasonable size into a buffer, and append() it. How large the chunks have to be depends on your input file size. I'm pretty sure all other portable and STL-compliant mechanisms will do the same (yet may look prettier).

Breaking

Since C++11 it is guaranteed to be OK to write directly into the std::string buffer; and I believe that it did work correctly on all actual implementations prior to that – Buffon

Since C++17 we even have non-const std::string::data() method for modifying string buffer directly without resorting to tricks like &str[0]. – Inoculum

Agreed with @Inoculum this answer is factually incorrect – Kaylyn

Answer 22

#include <iostream>
#include <fstream>
#include <string.h>
using namespace std;
main(){
    fstream file;
    //Open a file
    file.open("test.txt");
    string copy,temp;
    //While loop to store whole document in copy string
    //Temp reads a complete line
    //Loop stops until temp reads the last line of document
    while(getline(file,temp)){
        //add new line text in copy
        copy+=temp;
        //adds a new line
        copy+="\n";
    }
    //Display whole document
    cout<<copy;
    //close the document
    file.close();
}

Hyphen

Please add the description. – Bloodyminded

please visit and check how to answer a question. – Leftward

This is if you want to store it into a string. I would have added some description if the queue was not full. – Strati

The copy is a string variable saving whole text using in the code, you can assign them to another variable. – Hyphen

Answer 23

std::string get(std::string_view const& fn)
{
  struct filebuf: std::filebuf
  {
    using std::filebuf::egptr;
    using std::filebuf::gptr;

    using std::filebuf::gbump;
    using std::filebuf::underflow;
  };

  std::string r;

  if (filebuf fb; fb.open(fn.data(), std::ios::binary | std::ios::in))
  {
    r.reserve(fb.pubseekoff({}, std::ios::end));
    fb.pubseekpos({});

    while (filebuf::traits_type::eof() != fb.underflow())
    {
      auto const gptr(fb.gptr());
      auto const sz(fb.egptr() - gptr);

      fb.gbump(sz);
      r.append(gptr, sz);
    }
  }

  return r;
}

Faints

Answer 24

I know that I am late to the party, but now (2021) on my machine, this is the fastest implementation that I have tested:

#include <fstream>
#include <string>

bool fileRead( std::string &contents, const std::string &path ) {
    contents.clear();
    if( path.empty()) {
        return false;
    }
    std::ifstream stream( path );
    if( !stream ) {
        return false;
    }
    stream >> contents;
    return true;
}

Madox

… how did you test?! Because this is certainly not the fastest implementation, and it doesn’t read the entire file. – Requirement