205

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)
TylerH
  • 19,065
  • 49
  • 65
  • 86
  • 1
    Although not (quite) an exactly duplicate, this is closely related to: [how to pre-allocate memory for a std::string object?](http://stackoverflow.com/q/3303527/179910) (which, contrary to Konrad's statement above, included code to do this, reading the file directly into the destination, without doing an extra copy). – Jerry Coffin Sep 21 '12 at 15:11
  • 1
    "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. – Tino Didriksen Jul 19 '13 at 17:22
  • 2
    Related link: [How to read a file in C++?](http://insanecoding.blogspot.in/2011/11/how-to-read-in-file-in-c.html) -- benchmarks and discusses the various approaches. And yes, `rdbuf` (the one in the accepted answer) isn't the fastest, `read` is. – legends2k Nov 27 '14 at 04:24
  • 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? – Jason Cohen Sep 22 '08 at 16:51
  • 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'). – Ferruccio Sep 22 '08 at 16:54
  • 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. – Jason Cohen Sep 22 '08 at 16:56
  • 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! :) – kayleeFrye_onDeck Nov 01 '18 at 04:18

15 Answers15

149

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

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++14):

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

    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;
}
Konrad Rudolph
  • 482,603
  • 120
  • 884
  • 1,141
  • 23
    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? – sehe Sep 21 '12 at 14:32
  • 6
    @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. – DevSolar Sep 21 '12 at 14:36
  • 45
    @DevSolar 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?" – sehe Sep 21 '12 at 15:00
  • 1
    @sehe 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. – Konrad Rudolph Sep 24 '12 at 10:59
  • 1
    @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 :) – sehe Sep 24 '12 at 12:32
  • 3
    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. – David May 13 '13 at 20:18
  • 1
    @Dave Minimally faster – maybe. 10x? This hints at a defect in the standard library implementation. – Konrad Rudolph May 14 '13 at 03:59
  • 4
    Just wanted to add, that for someone learning C++, this is hard to understand at first glance. – Rahul Iyer Oct 13 '14 at 13:20
  • 2
    @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. – Konrad Rudolph Oct 13 '14 at 13:23
  • 14
    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 . – M.M Feb 06 '16 at 12:08
  • @M.M Good point, no idea how this slipped under the radar for so long. – Konrad Rudolph Feb 06 '16 at 12:30
  • @sehe 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! – Dan Nissenbaum Feb 12 '16 at 05:58
  • 10
    @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. – Konrad Rudolph Feb 12 '16 at 08:47
  • @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. – Dan Nissenbaum Feb 12 '16 at 12:24
  • @DanNissenbaum that's why lambdas were introduced :) – Ruslan Jun 29 '16 at 18:56
  • 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? – Maxpm May 22 '17 at 20:28
  • This way is slow (because std::stringstream is slow). – Galik Jul 15 '18 at 23:26
  • @Galik 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. – Konrad Rudolph Jul 16 '18 at 06:17
  • Why not `dynamic_cast` instead of `static_cast`? Aren't we just downcasting? – Ayxan Haqverdili Mar 03 '19 at 18:30
  • 2
    @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++. – Konrad Rudolph Mar 03 '19 at 18:38
  • Will this method trigger memory reallocation for many times ? – coin cheung Mar 11 '20 at 03:40
  • 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. – anton_rh Apr 27 '20 at 09:21
  • @anton_rh 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: https://en.cppreference.com/w/cpp/io/basic_ostream/operator_ltlt – Konrad Rudolph Apr 27 '20 at 10:09
61

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.

Konrad Rudolph
  • 482,603
  • 120
  • 884
  • 1,141
  • 7
    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? – Martin Beckett Sep 22 '08 at 17:19
  • @M.M The way I read that comparison, this method is slower than the pure C++ reading-into-a-preallocated-buffer method. – Konrad Rudolph Feb 06 '16 at 12:27
  • You're right, it's a case of the title being under the code sample, rather than above it :) – M.M Feb 06 '16 at 19:44
  • Will this method trigger memory reallocation for many times ? – coin cheung Mar 11 '20 at 03:39
  • @coincheung Unfortunately yes. If you want to avoid memory allocations you need to manually buffer the reading. C++ IO streams are pretty crap. – Konrad Rudolph Mar 16 '20 at 10:08
  • @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 ? – coin cheung Mar 16 '20 at 11:33
  • @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 https://gist.github.com/klmr/849cbb0c6e872dff0fdcc54787a66103. Unfortunately very verbose. – Konrad Rudolph Mar 16 '20 at 11:52
53

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

Deduplicator
  • 41,806
  • 6
  • 61
  • 104
paxos1977
  • 135,245
  • 26
  • 85
  • 125
  • 3
    related: time performance comparison of various methods: [Reading in an entire file at once in C++](http://insanecoding.blogspot.ru/2011/11/reading-in-entire-file-at-once-in-c.html) – jfs Dec 03 '14 at 20:17
  • 14
    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. http://stackoverflow.com/questions/22984956/tellg-function-give-wrong-size-of-file/22986486#22986486 – Puzomor Croatia Dec 27 '16 at 00:36
  • 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 – Andriy Tylychko Feb 09 '17 at 15:31
  • 1
    also you need to check for empty files as you'll dereference `nullptr` by `&bytes[0]` – Andriy Tylychko Feb 09 '17 at 15:32
  • ok, I've missed `ios::ate`, so I think a version with explicit moving to the end would be more readable – Andriy Tylychko Feb 09 '17 at 15:43
  • Note that this solution only works for binary mode; whereas the OP asked for a solution for both binary and text mode. – M.M Jun 12 '18 at 00:11
  • 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. – syam Dec 18 '18 at 06:44
  • 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). – spectras Feb 25 '21 at 09:25
  • @spectras can you point to a system or an implementation of C++ that is known not to return the offset in bytes? – paxos1977 Mar 15 '21 at 17:20
  • @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. – spectras Mar 16 '21 at 01:16
  • @spectras 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". – paxos1977 Mar 18 '21 at 17:48
  • 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]* – spectras Mar 18 '21 at 18:04
  • …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"*. – spectras Mar 18 '21 at 18:04
  • @spectras 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. – paxos1977 Mar 19 '21 at 16:24
  • @spectras "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. – paxos1977 Mar 19 '21 at 16:29
  • …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. – spectras Mar 19 '21 at 16:38
28

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.

kiroma
  • 91
  • 6
Gabriel Majeri
  • 397
  • 5
  • 5
  • 1
    This may cause undefined behaviour; opening the file in text mode yields a different stream than the disk file on some operating systems. – M.M Jun 12 '18 at 00:13
  • 1
    Originally developed as `boost::filesystem` so you can also use boost if you don't have c++17 – Gerhard Burger Sep 29 '18 at 11:11
  • 7
    Opening a file with one API and getting its size with another seems to be asking for inconsistency and race conditions. – Arthur Tacca Oct 24 '18 at 13:19
24

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.

Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
Ben Collins
  • 19,889
  • 16
  • 119
  • 182
17

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);
}
Rick Ramstetter
  • 312
  • 2
  • 8
  • 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](https://stackoverflow.com/a/22986486/3212865) for an example. – spectras Feb 25 '21 at 09:29
6

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.

tgnottingham
  • 198
  • 3
  • 11
5

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.

Matt Price
  • 38,782
  • 9
  • 34
  • 43
  • 1
    You should checkout the version of this code that uses std::vector for the initial read rather than a string. Much much faster. – paxos1977 Feb 08 '09 at 05:56
5

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()); };
David G
  • 4,158
  • 1
  • 19
  • 16
  • `infile.open` can also accept `std::string` without converting with `.c_str()` – Matt Eding Jan 02 '20 at 06:24
  • `filepath` isn't a `std::string`, it's a `std::filesystem::path`. Turns out `std::ifstream::open` can accept one of those as well. – David G Jan 09 '20 at 22:21
  • @DavidG, `std::filesystem::path` is implicitly convertible to `std::string` – Jeffrey Cash Feb 07 '20 at 11:53
  • 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. – David G Feb 18 '20 at 00:20
5

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.

b.g.
  • 728
  • 7
  • 11
3

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() ) );
Martin Cote
  • 26,618
  • 13
  • 71
  • 98
  • 5
    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. – David May 13 '13 at 20:16
  • 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. – Olaf Dietsche Aug 12 '17 at 10:37
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);
}

usage:

const string logAsString = GetFileAsString(logFilePath);
Paul Sumpner
  • 319
  • 4
  • 5
0

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.

kiroma
  • 91
  • 6
  • 2
    This code does not work, I'm getting empty string. I think you wanted `ifs.seekg(0)` instead of `ifs.clear()` (then it works). – Xeverous Jul 15 '20 at 09:46
-1

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).

Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
Thorsten79
  • 9,812
  • 5
  • 35
  • 51
  • 6
    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 – M.M Jul 15 '18 at 23:24
  • 2
    Since C++17 we even have non-const [`std::string::data()`](https://en.cppreference.com/w/cpp/string/basic_string/data) method for modifying string buffer directly without resorting to tricks like `&str[0]`. – zett42 Nov 15 '18 at 23:22
  • Agreed with @zett42 this answer is factually incorrect – jeremyong Mar 15 '19 at 22:24
-1
#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();
}