| <?xml version="1.0" encoding="UTF-8" standalone="no"?> | |
| <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>File Based Streams</title><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot" /><meta name="keywords" content="ISO C++, library" /><meta name="keywords" content="ISO C++, runtime, library" /><link rel="home" href="../index.html" title="The GNU C++ Library" /><link rel="up" href="io.html" title="Chapter 14. Input and Output" /><link rel="prev" href="stringstreams.html" title="Memory Based Streams" /><link rel="next" href="io_and_c.html" title="Interacting with C" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">File Based Streams</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="stringstreams.html">Prev</a> </td><th width="60%" align="center">Chapter 14. | |
| Input and Output | |
| </th><td width="20%" align="right"> <a accesskey="n" href="io_and_c.html">Next</a></td></tr></table><hr /></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="std.io.filestreams"></a>File Based Streams</h2></div></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="std.io.filestreams.copying_a_file"></a>Copying a File</h3></div></div></div><p> | |
| </p><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): | |
| </p><pre class="programlisting"> | |
| #include <fstream> | |
| std::ifstream IN ("input_file"); | |
| std::ofstream OUT ("output_file"); </pre><p>Here's the easiest way to get it completely wrong: | |
| </p><pre class="programlisting"> | |
| OUT << IN;</pre><p>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 "input_file" containing | |
| the sentence | |
| </p><pre class="programlisting"> | |
| The quick brown fox jumped over the lazy dog.</pre><p>surrounded by blank lines. Code it up and try it. The contents | |
| of "output_file" may surprise you. | |
| </p><p>Seriously, go do it. Get surprised, then come back. It's worth it. | |
| </p><p>The thing to remember is that the <code class="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 class="code">basic_streambuf</code> family. Fortunately, the | |
| <code class="code">operator<<</code> is overloaded to take an ostream and | |
| a pointer-to-streambuf, in order to help with just this kind of | |
| "dump the data verbatim" situation. | |
| </p><p>Why a <span class="emphasis"><em>pointer</em></span> 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 class="code">rdbuf()</code> member function. Therefore, the easiest | |
| way to copy the file is: | |
| </p><pre class="programlisting"> | |
| OUT << IN.rdbuf();</pre><p>So what <span class="emphasis"><em>was</em></span> happening with OUT<<IN? Undefined | |
| behavior, since that particular << 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 "Thequickbrownfox...". 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 hexadecimal | |
| address (quite a big surprise). Others don't compile at all. | |
| </p><p>Also note that none of this is specific to o<span class="emphasis"><em>*f*</em></span>streams. | |
| The operators shown above are all defined in the parent | |
| basic_ostream class and are therefore available with all possible | |
| descendants. | |
| </p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="std.io.filestreams.binary"></a>Binary Input and Output</h3></div></div></div><p> | |
| </p><p>The first and most important thing to remember about binary I/O is | |
| that opening a file with <code class="code">ios::binary</code> is not, repeat | |
| <span class="emphasis"><em>not</em></span>, the only thing you have to do. It is not a silver | |
| bullet, and will not allow you to use the <code class="code"><</>></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 "binary" | |
| covers a lot of ground), but we will try and clear | |
| up a couple of misconceptions and common errors. | |
| </p><p>First, <code class="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 class="code"><<</code> to write and <code class="code">>></code> to | |
| read isn't going to work with the standard file stream classes, even | |
| if you use <code class="code">skipws</code> during reading. Why not? Because | |
| ifstream and ofstream exist for the purpose of <span class="emphasis"><em>formatting</em></span>, | |
| 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 class="code">get()</code> and <code class="code">put()/write()</code> member | |
| functions still aren't guaranteed to help you. These are | |
| "unformatted" 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 <span class="emphasis"><em>formatting</em></span> functions and classes to perform something | |
| which <span class="emphasis"><em>requires</em></span> that formatting not be done? There are a | |
| seemingly infinite number of solutions, and a few are listed here: | |
| </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p><span class="quote">“<span class="quote">Derive your own fstream-type classes and write your own | |
| <</>> operators to do binary I/O on whatever data | |
| types you're using.</span>”</span> | |
| </p><p> | |
| 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. | |
| </p></li><li class="listitem"><p> | |
| <span class="quote">“<span class="quote">Build the file structure in memory, then | |
| <code class="code">mmap()</code> the file and copy the | |
| structure. | |
| </span>”</span> | |
| </p><p> | |
| Well, this is easy to make work, and easy to break, and is | |
| pretty equivalent to using <code class="code">::read()</code> and | |
| <code class="code">::write()</code> directly, and makes no use of the | |
| iostream library at all... | |
| </p></li><li class="listitem"><p> | |
| <span class="quote">“<span class="quote">Use streambufs, that's what they're there for.</span>”</span> | |
| </p><p> | |
| 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. | |
| </p></li></ul></div><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 class="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 class="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. | |
| </p><p> | |
| An instructive thread from comp.lang.c++.moderated delved off into | |
| this topic starting more or less at | |
| <a class="link" href="https://groups.google.com/forum/#!topic/comp.std.c++/D4e0q9eVSoc" target="_top">this post</a> | |
| and continuing to the end of the thread. (The subject heading is "binary iostreams" on both comp.std.c++ | |
| and comp.lang.c++.moderated.) Take special note of the replies by James Kanze and Dietmar Kühl. | |
| </p><p>Briefly, the problems of byte ordering and type sizes mean that | |
| the unformatted functions like <code class="code">ostream::put()</code> and | |
| <code class="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></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="stringstreams.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="io.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="io_and_c.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Memory Based Streams </td><td width="20%" align="center"><a accesskey="h" href="../index.html">Home</a></td><td width="40%" align="right" valign="top"> Interacting with C</td></tr></table></div></body></html> |