title: Optimal way of reading a complete file to a string using fstream?
body: <p>Many other posts, like " <a href="https://stackoverflow.com/questions/2602013/read-whole-ascii-file-into-c-stdstring">Read whole ASCII file into C++ std::string</a> " explain what some of the options are but do not describe pro and cons of various methods in any depth. I want to know why one method is preferable over another?</p>
  
  <p>All of these use <code>std::fstream</code> to read the file into a <code>std::string</code>. I am unsure what the costs and benefits of each method. Lets assume this is for the common case where the read files are known to be of some smallish size memory can easily accommodate, clearly reading a multi-terrabyte file into an memory is a bad idea no matter how you do it.</p>
  
  <p>The most common way after a few googles searches to read a whole file into an std::string involves using <code>std::getline</code> and appending a newline character to it after each line. This seems needless to me, but is there some performance or compatibility reason that this is ideal?</p>
  
  <pre><code>std::string Results;
  std::ifstream ResultReader("file.txt");    
  while(ResultReader)
  {
      std::getline(ResultReader, Results);
      Results.push_back('\n');
  }
  </code></pre>
  
  <p>Another way I pieced together is to change the getline delimiter so it is something not in the file. The EOF char is seems unlikely to be in the middle of the file so that seems a likely candidate. This includes a cast so there is at least one reason not to do it, but this does read a file at once with no string concatenation. Presumably there is still some cost for the delimiter checks. Are there any other good reasons not to do this?</p>
  
  <pre><code>std::string Results;
  std::ifstream ResultReader("file.txt");
  std::getline(ResultReader, Results, (char)std::char_traits&lt;char&gt;::eof());
  </code></pre>
  
  <p>The cast means that on systems that define std::char_traits::eof() as something other than -1 might have problems. Is this a practical reason  to not choose this over other methods that use <code>std::getline</code> and <code>string::push_pack('\n')</code>.</p>
  
  <p>How does these compare to other ways of reading the file at once like in this question: <a href="https://stackoverflow.com/questions/2602013/read-whole-ascii-file-into-c-stdstring">Read whole ASCII file into C++ std::string</a></p>
  
  <pre><code>std::ifstream ResultReader("file.txt");
  std::string Results((std::istreambuf_iterator&lt;char&gt;(ResultReader)),
                       std::istreambuf_iterator&lt;char&gt;());
  </code></pre>
  
  <p>It would seem this would be best. It offloads almost all the work onto the standard library which ought to be heavily optimized for the given platform. I see no reason for checks other than stream validity and the end of the file. Is this ideal or are there problems with this that are unseen.</p>
  
  <p>Does the standard or do details of some implementation provide reasons to prefer some method over another? Have I missed some method that might prove ideal in a wide variety of circumstances?</p>
  
  <p>What is a simplest, most idiomatic, best performing and standard compliant way of reading a whole file into an <code>std::string</code>?</p>
  
  <p><strong>EDIT - 2</strong>
  This question has prompted me to write a small suite of benchmarks. They are MIT license and available on github at: <a href="https://github.com/Sqeaky/CppFileToStringExperiments" rel="nofollow noreferrer">https://github.com/Sqeaky/CppFileToStringExperiments</a></p>
  
  <p><em>Fastest</em> - TellSeekRead and CTellSeekRead- These have the system provide an easy to get the size and reads the file in one go.</p>
  
  <p><em>Faster</em> - Getline Appending and Eof - The checking of chars does not seem to impose any cost.</p>
  
  <p><em>Fast</em> - RdbufMove and Rdbuf -  The std::move seems to make no difference in release.</p>
  
  <p><em>Slow</em> - Iterator, BackInsertIterator and AssignIterator - Something is wrong with iterators and input streams. The work great in memory, but not here. That said some of these are faster than others.</p>
  
  <p>I have added every method suggested so far, including those in links. I would appreciate if someone could run this on windows and with other compilers. I currently do not have access to a machine with NTFS and it has been noted that this and compiler details could be important.</p>
  
  <p>As for measuring simplicity and idiomatic-ness how do we measure these objectively? Simplicity seems doable, perhaps use something line LOCs and Cyclomatic complexity, but how idiomatic something is seems purely subjective.</p>