gcc/libstdc++-v3/docs/html/27_io/howto.html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<html>
<head>
   <meta HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
   <meta NAME="AUTHOR" CONTENT="pme@gcc.gnu.org (Phil Edwards)">
   <meta NAME="KEYWORDS" CONTENT="HOWTO, libstdc++, GCC, g++, libg++, STL">
   <meta NAME="DESCRIPTION" CONTENT="HOWTO for the libstdc++ chapter 27.">
   <meta NAME="GENERATOR" CONTENT="vi and eight fingers">
   <title>libstdc++-v3 HOWTO:  Chapter 27</title>
<link REL=StyleSheet HREF="../lib3styles.css">
</head>
<body>

<h1 CLASS="centered"><a name="top">Chapter 27:  Input/Output</a></h1>

<p>Chapter 27 deals with iostreams and all their subcomponents
   and extensions.  All <em>kinds</em> of fun stuff.
</p>


<!-- ####################################################### -->
<hr>
<h1>Contents</h1>
<ul>
   <li><a href="#1">Copying a file</a>
   <li><a href="#2">The buffering is screwing up my program!</a>
   <li><a href="#3">Binary I/O</a>
   <li><a href="#5">What is this &lt;sstream&gt;/stringstreams thing?</a>
   <li><a href="#6">Deriving a stream buffer</a>
   <li><a href="#7">More on binary I/O</a>
   <li><a href="#8">Pathetic performance?  Ditch C.</a>
</ul>

<hr>

<!-- ####################################################### -->

<h2><a name="1">Copying a file</a></h2>
   <p>So you want to copy a file quickly and easily, and most important,
      completely portably.  And since this is C++, you have an open
      ifstream (call it IN) and an open ofstream (call it OUT):
      <PRE>
   #include &lt;fstream&gt;

   std::ifstream  IN ("input_file");
   std::ofstream  OUT ("output_file"); </PRE>
   </p>
   <p>Here's the easiest way to get it completely wrong:
      <PRE>
   OUT &lt;&lt; IN;</PRE>
      For those of you who don't already know why this doesn't work
      (probably from having done it before), I invite you to quickly
      create a simple text file called &quot;input_file&quot; containing
      the sentence
      <PRE>
   The quick brown fox jumped over the lazy dog.</PRE>
      surrounded by blank lines.  Code it up and try it.  The contents
      of &quot;output_file&quot; may surprise you.
   </p>
   <p>Seriously, go do it.  Get surprised, then come back.  It's worth it.
   </p>
   <HR WIDTH="60%">
   <p>The thing to remember is that the <code>basic_[io]stream</code> classes
      handle formatting, nothing else.  In particular, they break up on
      whitespace.  The actual reading, writing, and storing of data is
      handled by the <code>basic_streambuf</code> family.  Fortunately, the
      <code>operator&lt;&lt;</code> is overloaded to take an ostream and
      a pointer-to-streambuf, in order to help with just this kind of
      &quot;dump the data verbatim&quot; situation.
   </p>
   <p>Why a <em>pointer</em> to streambuf and not just a streambuf?  Well,
      the [io]streams hold pointers (or references, depending on the
      implementation) to their buffers, not the actual
      buffers.  This allows polymorphic behavior on the part of the buffers
      as well as the streams themselves.  The pointer is easily retrieved
      using the <code>rdbuf()</code> member function.  Therefore, the easiest
      way to copy the file is:
      <PRE>
   OUT &lt;&lt; IN.rdbuf();</PRE>
   </p>
   <p>So what <em>was</em> happening with OUT&lt;&lt;IN?  Undefined
      behavior, since that particular &lt;&lt; isn't defined by the Standard.
      I have seen instances where it is implemented, but the character
      extraction process removes all the whitespace, leaving you with no
      blank lines and only &quot;Thequickbrownfox...&quot;.  With
      libraries that do not define that operator, IN (or one of IN's
      member pointers) sometimes gets converted to a void*, and the output
      file then contains a perfect text representation of a hexidecimal
      address (quite a big surprise).  Others don't compile at all.
   </p>
   <p>Also note that none of this is specific to o<B>*f*</B>streams. 
      The operators shown above are all defined in the parent 
      basic_ostream class and are therefore available with all possible
      descendents.
   </p>
   <p>Return <a href="#top">to top of page</a> or
      <a href="../faq/index.html">to the FAQ</a>.
   </p>

<hr>
<h2><a name="2">The buffering is screwing up my program!</a></h2>
<!--
  This is not written very well.  I need to redo this section.
-->
   <p>First, are you sure that you understand buffering?  Particularly
      the fact that C++ may not, in fact, have anything to do with it?
   </p>
   <p>The rules for buffering can be a little odd, but they aren't any
      different from those of C.  (Maybe that's why they can be a bit
      odd.)  Many people think that writing a newline to an output
      stream automatically flushes the output buffer.  This is true only
      when the output stream is, in fact, a terminal and not a file
      or some other device -- and <em>that</em> may not even be true
      since C++ says nothing about files nor terminals.  All of that is
      system-dependant.  (The &quot;newline-buffer-flushing only occuring
      on terminals&quot; thing is mostly true on Unix systems, though.)
   </p>
   <p>Some people also believe that sending <code>endl</code> down an
      output stream only writes a newline.  This is incorrect; after a
      newline is written, the buffer is also flushed.  Perhaps this
      is the effect you want when writing to a screen -- get the text
      out as soon as possible, etc -- but the buffering is largely
      wasted when doing this to a file:
      <PRE>
   output &lt;&lt; &quot;a line of text&quot; &lt;&lt; endl;
   output &lt;&lt; some_data_variable &lt;&lt; endl;
   output &lt;&lt; &quot;another line of text&quot; &lt;&lt; endl; </PRE>
      The proper thing to do in this case to just write the data out
      and let the libraries and the system worry about the buffering.
      If you need a newline, just write a newline:
      <PRE>
   output &lt;&lt; &quot;a line of text\n&quot;
          &lt;&lt; some_data_variable &lt;&lt; '\n'
          &lt;&lt; &quot;another line of text\n&quot;; </PRE>
      I have also joined the output statements into a single statement.
      You could make the code prettier by moving the single newline to
      the start of the quoted text on the thing line, for example.
   </p>
   <p>If you do need to flush the buffer above, you can send an
      <code>endl</code> if you also need a newline, or just flush the buffer
      yourself:
      <PRE>
   output &lt;&lt; ...... &lt;&lt; flush;    // can use std::flush manipulator
   output.flush();               // or call a member fn </PRE>
   </p>
   <p>On the other hand, there are times when writing to a file should
      be like writing to standard error; no buffering should be done 
      because the data needs to appear quickly (a prime example is a
      log file for security-related information).  The way to do this is
      just to turn off the buffering <em>before any I/O operations at
      all</em> have been done, i.e., as soon as possible after opening:
      <PRE>
   std::ofstream    os (&quot;/foo/bar/baz&quot;);
   std::ifstream    is (&quot;/qux/quux/quuux&quot;);
   int   i;

   os.rdbuf()-&gt;pubsetbuf(0,0);
   is.rdbuf()-&gt;pubsetbuf(0,0);
   ...
   os &lt;&lt; &quot;this data is written immediately\n&quot;;
   is &gt;&gt; i;   // and this will probably cause a disk read </PRE>
   </p>
   <p>Since all aspects of buffering are handled by a streambuf-derived
      member, it is necessary to get at that member with <code>rdbuf()</code>.
      Then the public version of <code>setbuf</code> can be called.  The 
      arguments are the same as those for the Standard C I/O Library
      function (a buffer area followed by its size).
   </p>
   <p>A great deal of this is implementation-dependant.  For example,
      <code>streambuf</code> does not specify any actions for its own 
      <code>setbuf()</code>-ish functions; the classes derived from
      <code>streambuf</code> each define behavior that &quot;makes 
      sense&quot; for that class:  an argument of (0,0) turns off
      buffering for <code>filebuf</code> but has undefined behavior for
      its sibling <code>stringbuf</code>, and specifying anything other
      than (0,0) has varying effects.  Other user-defined class derived
      from streambuf can do whatever they want.
   </p>
   <p>A last reminder:  there are usually more buffers involved than
      just those at the language/library level.  Kernel buffers, disk
      buffers, and the like will also have an effect.  Inspecting and
      changing those are system-dependant.
   </p>
   <p>Return <a href="#top">to top of page</a> or
      <a href="../faq/index.html">to the FAQ</a>.
   </p>

<hr>
<h2><a name="3">Binary I/O</a></h2>
   <p>The first and most important thing to remember about binary I/O is
      that opening a file with <code>ios::binary</code> is not, repeat
      <em>not</em>, the only thing you have to do.  It is not a silver
      bullet, and will not allow you to use the <code>&lt;&lt;/&gt;&gt;</code>
      operators of the normal fstreams to do binary I/O.
   </p>
   <p>Sorry.  Them's the breaks.
   </p>
   <p>This isn't going to try and be a complete tutorial on reading and
      writing binary files (because &quot;binary&quot;
      <a href="#7">covers a lot of ground)</a>, but we will try and clear
      up a couple of misconceptions and common errors.
   </p>
   <p>First, <code>ios::binary</code> has exactly one defined effect, no more
      and no less.  Normal text mode has to be concerned with the newline
      characters, and the runtime system will translate between (for
      example) '\n' and the appropriate end-of-line sequence (LF on Unix,
      CRLF on DOS, CR on Macintosh, etc).  (There are other things that
      normal mode does, but that's the most obvious.)  Opening a file in
      binary mode disables this conversion, so reading a CRLF sequence
      under Windows won't accidentally get mapped to a '\n' character, etc.
      Binary mode is not supposed to suddenly give you a bitstream, and
      if it is doing so in your program then you've discovered a bug in
      your vendor's compiler (or some other part of the C++ implementation,
      possibly the runtime system).
   </p>
   <p>Second, using <code>&lt;&lt;</code> to write and <code>&gt;&gt;</code> to
      read isn't going to work with the standard file stream classes, even
      if you use <code>skipws</code> during reading.  Why not?  Because 
      ifstream and ofstream exist for the purpose of <em>formatting</em>,
      not reading and writing.  Their job is to interpret the data into
      text characters, and that's exactly what you don't want to happen
      during binary I/O.
   </p>
   <p>Third, using the <code>get()</code> and <code>put()/write()</code> member
      functions still aren't guaranteed to help you.  These are
      &quot;unformatted&quot; I/O functions, but still character-based.
      (This may or may not be what you want, see below.)
   </p>
   <p>Notice how all the problems here are due to the inappropriate use
      of <em>formatting</em> functions and classes to perform something
      which <em>requires</em> that formatting not be done?  There are a
      seemingly infinite number of solutions, and a few are listed here:
      <ul>
        <li>&quot;Derive your own fstream-type classes and write your own
            &lt;&lt;/&gt;&gt; operators to do binary I/O on whatever data
            types you're using.&quot;  This is a Bad Thing, because while
            the compiler would probably be just fine with it, other humans
            are going to be confused.  The overloaded bitshift operators
            have a well-defined meaning (formatting), and this breaks it.
        <li>&quot;Build the file structure in memory, then <code>mmap()</code>
            the file and copy the structure.&quot;  Well, this is easy to
            make work, and easy to break, and is pretty equivalent to
            using <code>::read()</code> and <code>::write()</code> directly, and
            makes no use of the iostream library at all...
        <li>&quot;Use streambufs, that's what they're there for.&quot;
            While not trivial for the beginner, this is the best of all
            solutions.  The streambuf/filebuf layer is the layer that is
            responsible for actual I/O.  If you want to use the C++
            library for binary I/O, this is where you start.
      </ul>
   </p>
   <p>How to go about using streambufs is a bit beyond the scope of this
      document (at least for now), but while streambufs go a long way,
      they still leave a couple of things up to you, the programmer.
      As an example, byte ordering is completely between you and the
      operating system, and you have to handle it yourself.
   </p>
   <p>Deriving a streambuf or filebuf
      class from the standard ones, one that is specific to your data
      types (or an abstraction thereof) is probably a good idea, and
      lots of examples exist in journals and on Usenet.  Using the
      standard filebufs directly (either by declaring your own or by
      using the pointer returned from an fstream's <code>rdbuf()</code>)
      is certainly feasible as well.
   </p>
   <p>One area that causes problems is trying to do bit-by-bit operations
      with filebufs.  C++ is no different from C in this respect:  I/O
      must be done at the byte level.  If you're trying to read or write
      a few bits at a time, you're going about it the wrong way.  You
      must read/write an integral number of bytes and then process the
      bytes.  (For example, the streambuf functions take and return
      variables of type <code>int_type</code>.)
   </p>
   <p>Another area of problems is opening text files in binary mode.
      Generally, binary mode is intended for binary files, and opening
      text files in binary mode means that you now have to deal with all of 
      those end-of-line and end-of-file problems that we mentioned before.
      An instructive thread from comp.lang.c++.moderated delved off into
      this topic starting more or less at
      <a href="http://www.deja.com/getdoc.xp?AN=436187505">this</a>
      article and continuing to the end of the thread.  (You'll have to
      sort through some flames every couple of paragraphs, but the points
      made are good ones.)
   </p>
 
<hr>
<h2><a name="5">What is this &lt;sstream&gt;/stringstreams thing?</a></h2>
   <p>Stringstreams (defined in the header <code>&lt;sstream&gt;</code>)
      are in this author's opinion one of the coolest things since
      sliced time.  An example of their use is in the Received Wisdom
      section for Chapter 21 (Strings),
      <a href="../21_strings/howto.html#1.1internal"> describing how to
      format strings</a>.
   </p>
   <p>The quick definition is:  they are siblings of ifstream and ofstream,
      and they do for <code>std::string</code> what their siblings do for
      files.  All that work you put into writing <code>&lt;&lt;</code> and
      <code>&gt;&gt;</code> functions for your classes now pays off
      <em>again!</em>  Need to format a string before passing the string
      to a function?  Send your stuff via <code>&lt;&lt;</code> to an
      ostringstream.  You've read a string as input and need to parse it?
      Initialize an istringstream with that string, and then pull pieces
      out of it with <code>&gt;&gt;</code>.  Have a stringstream and need to
      get a copy of the string inside?  Just call the <code>str()</code>
      member function.
   </p>
   <p>This only works if you've written your
      <code>&lt;&lt;</code>/<code>&gt;&gt;</code> functions correctly, though,
      and correctly means that they take istreams and ostreams as
      parameters, not i<B>f</B>streams and o<B>f</B>streams.  If they
      take the latter, then your I/O operators will work fine with
      file streams, but with nothing else -- including stringstreams.
   </p>
   <p>If you are a user of the strstream classes, you need to update
      your code.  You don't have to explicitly append <code>ends</code> to
      terminate the C-style character array, you don't have to mess with
      &quot;freezing&quot; functions, and you don't have to manage the
      memory yourself.  The strstreams have been officially deprecated,
      which means that 1) future revisions of the C++ Standard won't
      support them, and 2) if you use them, people will laugh at you.
   </p>

<hr>
<h2><a name="6">Deriving a stream buffer</a></h2>
   <p>Creating your own stream buffers for I/O can be remarkably easy.
      If you are interested in doing so, we highly recommend two very
      excellent books:  <em>Standard C++ IOStreams and Locales</em> by
      Langer and Kreft, ISBN 0-201-18395-1, and
      <a href="http://www.josuttis.com/libbook/">The C++ Standard Library</a>
      by Nicolai Josuttis, ISBN 0-201-37926-0.  Both are published by
      Addison-Wesley, who isn't paying us a cent for saying that, honest.
   </p>
   <p>Here is a simple example, io/outbuf1, from the Josuttis text.  It
      transforms everything sent through it to uppercase.  This version
      assumes many things about the nature of the character type being
      used (for more information, read the books or the newsgroups):
      <PRE>
    #include &lt;iostream&gt;
    #include &lt;streambuf&gt;
    #include &lt;locale&gt;
    #include &lt;cstdio&gt;

    class outbuf : public std::streambuf
    {
      protected:
	/* central output function
	 * - print characters in uppercase mode
	 */
	virtual int_type overflow (int_type c) {
	    if (c != EOF) {
		// convert lowercase to uppercase
		c = std::toupper(static_cast&lt;char&gt;(c),getloc());

		// and write the character to the standard output
		if (putchar(c) == EOF) {
		    return EOF;
		}
	    }
	    return c;
	}
    };

    int main()
    {
	// create special output buffer
	outbuf ob;
	// initialize output stream with that output buffer
	std::ostream out(&ob);

	out &lt;&lt; "31 hexadecimal: "
	    &lt;&lt; std::hex &lt;&lt; 31 &lt;&lt; std::endl;
	return 0;
    }
   </PRE>
      Try it yourself!
   </p>

<hr>
<h2><a name="7">More on binary I/O</a></h2>
   <p>Towards the beginning of February 2001, the subject of
      &quot;binary&quot; I/O was brought up in a couple of places at the
      same time.  One notable place was Usenet, where James Kanze and
      Dietmar K&uuml;hl separately posted articles on why attempting
      generic binary I/O was not a good idea.  (Here are copies of
      <a href="binary_iostreams_kanze.txt">Kanze's article</a> and
      <a href="binary_iostreams_kuehl.txt">K&uuml;hl's article</a>.)
   </p>
   <p>Briefly, the problems of byte ordering and type sizes mean that
      the unformatted functions like <code>ostream::put()</code> and
      <code>istream::get()</code> cannot safely be used to communicate
      between arbitrary programs, or across a network, or from one
      invocation of a program to another invocation of the same program
      on a different platform, etc.
   </p>
   <p>The entire Usenet thread is instructive, and took place under the
      subject heading &quot;binary iostreams&quot; on both comp.std.c++
      and comp.lang.c++.moderated in parallel.  Also in that thread,
      Dietmar K&uuml;hl mentioned that he had written a pair of stream
      classes that would read and write XDR, which is a good step towards
      a portable binary format.
   </p>

<hr>
<h2><a name="8">Pathetic performance?  Ditch C.</a></h2>
   <p>It sounds like a flame on C, but it isn't.  Really.  Calm down.
      I'm just saying it to get your attention.
   </p>
   <p>Because the C++ library includes the C library, both C-style and
      C++-style I/O have to work at the same time.  For example:
      <PRE>
     #include &lt;iostream&gt;
     #include &lt;cstdio&gt;

     std::cout &lt;&lt; &quot;Hel&quot;;
     std::printf (&quot;lo, worl&quot;);
     std::cout &lt;&lt; &quot;d!\n&quot;;
      </PRE>
      This must do what you think it does.
   </p>
   <p>Alert members of the audience will immediately notice that buffering
      is going to make a hash of the output unless special steps are taken.
   </p>
   <p>The special steps taken by libstdc++, at least for version 3.0,
      involve doing very little buffering for the standard streams, leaving
      most of the buffering to the underlying C library.  (This kind of
      thing is <a href="../explanations.html#cstdio">tricky to get right</a>.)
      The upside is that correctness is ensured.  The downside is that
      writing through <code>cout</code> can quite easily lead to awful
      performance when the C++ I/O library is layered on top of the C I/O
      library (as it is for 3.0 by default).  Some patches are in the
      works which should improve the situation for 3.1.
   </p>
   <p>However, the C and C++ standard streams only need to be kept in sync
      when both libraries' facilities are in use.  If your program only uses
      C++ I/O, then there's no need to sync with the C streams.  The right
      thing to do in this case is to call
      <PRE>
     #include <em>any of the I/O headers such as ios, iostream, etc</em>

     std::ios::sync_with_stdio(false);
      </PRE>
   </p>
   <p>You must do this before performing any I/O via the C++ stream objects.
      Once you call this, the C++ streams will operate independantly of the
      (unused) C streams.  For GCC 3.0, this means that <code>cout</code> and
      company will become fully buffered on their own.
   </p>
   <p>Note, by the way, that the synchronization requirement only applies to
      the standard streams (<code>cin</code>, <code>cout</code>, <code>cerr</code>,
      <code>clog</code>, and their wide-character counterparts).  File stream
      objects that you create yourself have no such requirement and are fully
      buffered.
   </p>


<!-- ####################################################### -->

<hr><br><br><br><br><br><br><br><br>
<P CLASS="fineprint"><em>
See <a href="../17_intro/license.html">license.html</a> for copying conditions.
Comments and suggestions are welcome, and may be sent to
<a href="mailto:libstdc++@gcc.gnu.org">the mailing list</a>.
</em></p>


</body>
</html>