1*03a78d15Sespie<?xml version="1.0" encoding="ISO-8859-1"?> 2*03a78d15Sespie<!DOCTYPE html 3*03a78d15Sespie PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 4*03a78d15Sespie "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> 5*03a78d15Sespie 6*03a78d15Sespie<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> 7*03a78d15Sespie<head> 8*03a78d15Sespie <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" /> 9*03a78d15Sespie <meta name="AUTHOR" content="pme@gcc.gnu.org (Phil Edwards)" /> 10*03a78d15Sespie <meta name="KEYWORDS" content="HOWTO, libstdc++, GCC, g++, libg++, STL" /> 11*03a78d15Sespie <meta name="DESCRIPTION" content="HOWTO for the libstdc++ chapter 27." /> 12*03a78d15Sespie <meta name="GENERATOR" content="vi and eight fingers" /> 13*03a78d15Sespie <title>libstdc++-v3 HOWTO: Chapter 27</title> 14*03a78d15Sespie<link rel="StyleSheet" href="../lib3styles.css" /> 15*03a78d15Sespie</head> 16*03a78d15Sespie<body> 17*03a78d15Sespie 18*03a78d15Sespie<h1 class="centered"><a name="top">Chapter 27: Input/Output</a></h1> 19*03a78d15Sespie 20*03a78d15Sespie<p>Chapter 27 deals with iostreams and all their subcomponents 21*03a78d15Sespie and extensions. All <em>kinds</em> of fun stuff. 22*03a78d15Sespie</p> 23*03a78d15Sespie 24*03a78d15Sespie 25*03a78d15Sespie<!-- ####################################################### --> 26*03a78d15Sespie<hr /> 27*03a78d15Sespie<h1>Contents</h1> 28*03a78d15Sespie<ul> 29*03a78d15Sespie <li><a href="#1">Copying a file</a></li> 30*03a78d15Sespie <li><a href="#2">The buffering is screwing up my program!</a></li> 31*03a78d15Sespie <li><a href="#3">Binary I/O</a></li> 32*03a78d15Sespie <li><a href="#5">What is this <sstream>/stringstreams thing?</a></li> 33*03a78d15Sespie <li><a href="#6">Deriving a stream buffer</a></li> 34*03a78d15Sespie <li><a href="#7">More on binary I/O</a></li> 35*03a78d15Sespie <li><a href="#8">Pathetic performance? Ditch C.</a></li> 36*03a78d15Sespie <li><a href="#9">Threads and I/O</a></li> 37*03a78d15Sespie <li><a href="#10">Which header?</a></li> 38*03a78d15Sespie <li><a href="#11">Using FILE*s and file descriptors with IOStreams</a></li> 39*03a78d15Sespie</ul> 40*03a78d15Sespie 41*03a78d15Sespie<hr /> 42*03a78d15Sespie 43*03a78d15Sespie<!-- ####################################################### --> 44*03a78d15Sespie 45*03a78d15Sespie<h2><a name="1">Copying a file</a></h2> 46*03a78d15Sespie <p>So you want to copy a file quickly and easily, and most important, 47*03a78d15Sespie completely portably. And since this is C++, you have an open 48*03a78d15Sespie ifstream (call it IN) and an open ofstream (call it OUT): 49*03a78d15Sespie </p> 50*03a78d15Sespie <pre> 51*03a78d15Sespie #include <fstream> 52*03a78d15Sespie 53*03a78d15Sespie std::ifstream IN ("input_file"); 54*03a78d15Sespie std::ofstream OUT ("output_file"); </pre> 55*03a78d15Sespie <p>Here's the easiest way to get it completely wrong: 56*03a78d15Sespie </p> 57*03a78d15Sespie <pre> 58*03a78d15Sespie OUT << IN;</pre> 59*03a78d15Sespie <p>For those of you who don't already know why this doesn't work 60*03a78d15Sespie (probably from having done it before), I invite you to quickly 61*03a78d15Sespie create a simple text file called "input_file" containing 62*03a78d15Sespie the sentence 63*03a78d15Sespie </p> 64*03a78d15Sespie <pre> 65*03a78d15Sespie The quick brown fox jumped over the lazy dog.</pre> 66*03a78d15Sespie <p>surrounded by blank lines. Code it up and try it. The contents 67*03a78d15Sespie of "output_file" may surprise you. 68*03a78d15Sespie </p> 69*03a78d15Sespie <p>Seriously, go do it. Get surprised, then come back. It's worth it. 70*03a78d15Sespie </p> 71*03a78d15Sespie <hr width="60%" /> 72*03a78d15Sespie <p>The thing to remember is that the <code>basic_[io]stream</code> classes 73*03a78d15Sespie handle formatting, nothing else. In particular, they break up on 74*03a78d15Sespie whitespace. The actual reading, writing, and storing of data is 75*03a78d15Sespie handled by the <code>basic_streambuf</code> family. Fortunately, the 76*03a78d15Sespie <code>operator<<</code> is overloaded to take an ostream and 77*03a78d15Sespie a pointer-to-streambuf, in order to help with just this kind of 78*03a78d15Sespie "dump the data verbatim" situation. 79*03a78d15Sespie </p> 80*03a78d15Sespie <p>Why a <em>pointer</em> to streambuf and not just a streambuf? Well, 81*03a78d15Sespie the [io]streams hold pointers (or references, depending on the 82*03a78d15Sespie implementation) to their buffers, not the actual 83*03a78d15Sespie buffers. This allows polymorphic behavior on the part of the buffers 84*03a78d15Sespie as well as the streams themselves. The pointer is easily retrieved 85*03a78d15Sespie using the <code>rdbuf()</code> member function. Therefore, the easiest 86*03a78d15Sespie way to copy the file is: 87*03a78d15Sespie </p> 88*03a78d15Sespie <pre> 89*03a78d15Sespie OUT << IN.rdbuf();</pre> 90*03a78d15Sespie <p>So what <em>was</em> happening with OUT<<IN? Undefined 91*03a78d15Sespie behavior, since that particular << isn't defined by the Standard. 92*03a78d15Sespie I have seen instances where it is implemented, but the character 93*03a78d15Sespie extraction process removes all the whitespace, leaving you with no 94*03a78d15Sespie blank lines and only "Thequickbrownfox...". With 95*03a78d15Sespie libraries that do not define that operator, IN (or one of IN's 96*03a78d15Sespie member pointers) sometimes gets converted to a void*, and the output 97*03a78d15Sespie file then contains a perfect text representation of a hexidecimal 98*03a78d15Sespie address (quite a big surprise). Others don't compile at all. 99*03a78d15Sespie </p> 100*03a78d15Sespie <p>Also note that none of this is specific to o<b>*f*</b>streams. 101*03a78d15Sespie The operators shown above are all defined in the parent 102*03a78d15Sespie basic_ostream class and are therefore available with all possible 103*03a78d15Sespie descendents. 104*03a78d15Sespie </p> 105*03a78d15Sespie <p>Return <a href="#top">to top of page</a> or 106*03a78d15Sespie <a href="../faq/index.html">to the FAQ</a>. 107*03a78d15Sespie </p> 108*03a78d15Sespie 109*03a78d15Sespie<hr /> 110*03a78d15Sespie<h2><a name="2">The buffering is screwing up my program!</a></h2> 111*03a78d15Sespie<!-- 112*03a78d15Sespie This is not written very well. I need to redo this section. 113*03a78d15Sespie--> 114*03a78d15Sespie <p>First, are you sure that you understand buffering? Particularly 115*03a78d15Sespie the fact that C++ may not, in fact, have anything to do with it? 116*03a78d15Sespie </p> 117*03a78d15Sespie <p>The rules for buffering can be a little odd, but they aren't any 118*03a78d15Sespie different from those of C. (Maybe that's why they can be a bit 119*03a78d15Sespie odd.) Many people think that writing a newline to an output 120*03a78d15Sespie stream automatically flushes the output buffer. This is true only 121*03a78d15Sespie when the output stream is, in fact, a terminal and not a file 122*03a78d15Sespie or some other device -- and <em>that</em> may not even be true 123*03a78d15Sespie since C++ says nothing about files nor terminals. All of that is 124*03a78d15Sespie system-dependent. (The "newline-buffer-flushing only occurring 125*03a78d15Sespie on terminals" thing is mostly true on Unix systems, though.) 126*03a78d15Sespie </p> 127*03a78d15Sespie <p>Some people also believe that sending <code>endl</code> down an 128*03a78d15Sespie output stream only writes a newline. This is incorrect; after a 129*03a78d15Sespie newline is written, the buffer is also flushed. Perhaps this 130*03a78d15Sespie is the effect you want when writing to a screen -- get the text 131*03a78d15Sespie out as soon as possible, etc -- but the buffering is largely 132*03a78d15Sespie wasted when doing this to a file: 133*03a78d15Sespie </p> 134*03a78d15Sespie <pre> 135*03a78d15Sespie output << "a line of text" << endl; 136*03a78d15Sespie output << some_data_variable << endl; 137*03a78d15Sespie output << "another line of text" << endl; </pre> 138*03a78d15Sespie <p>The proper thing to do in this case to just write the data out 139*03a78d15Sespie and let the libraries and the system worry about the buffering. 140*03a78d15Sespie If you need a newline, just write a newline: 141*03a78d15Sespie </p> 142*03a78d15Sespie <pre> 143*03a78d15Sespie output << "a line of text\n" 144*03a78d15Sespie << some_data_variable << '\n' 145*03a78d15Sespie << "another line of text\n"; </pre> 146*03a78d15Sespie <p>I have also joined the output statements into a single statement. 147*03a78d15Sespie You could make the code prettier by moving the single newline to 148*03a78d15Sespie the start of the quoted text on the thing line, for example. 149*03a78d15Sespie </p> 150*03a78d15Sespie <p>If you do need to flush the buffer above, you can send an 151*03a78d15Sespie <code>endl</code> if you also need a newline, or just flush the buffer 152*03a78d15Sespie yourself: 153*03a78d15Sespie </p> 154*03a78d15Sespie <pre> 155*03a78d15Sespie output << ...... << flush; // can use std::flush manipulator 156*03a78d15Sespie output.flush(); // or call a member fn </pre> 157*03a78d15Sespie <p>On the other hand, there are times when writing to a file should 158*03a78d15Sespie be like writing to standard error; no buffering should be done 159*03a78d15Sespie because the data needs to appear quickly (a prime example is a 160*03a78d15Sespie log file for security-related information). The way to do this is 161*03a78d15Sespie just to turn off the buffering <em>before any I/O operations at 162*03a78d15Sespie all</em> have been done (note that opening counts as an I/O operation): 163*03a78d15Sespie </p> 164*03a78d15Sespie <pre> 165*03a78d15Sespie std::ofstream os; 166*03a78d15Sespie std::ifstream is; 167*03a78d15Sespie int i; 168*03a78d15Sespie 169*03a78d15Sespie os.rdbuf()->pubsetbuf(0,0); 170*03a78d15Sespie is.rdbuf()->pubsetbuf(0,0); 171*03a78d15Sespie 172*03a78d15Sespie os.open("/foo/bar/baz"); 173*03a78d15Sespie is.open("/qux/quux/quuux"); 174*03a78d15Sespie ... 175*03a78d15Sespie os << "this data is written immediately\n"; 176*03a78d15Sespie is >> i; // and this will probably cause a disk read </pre> 177*03a78d15Sespie <p>Since all aspects of buffering are handled by a streambuf-derived 178*03a78d15Sespie member, it is necessary to get at that member with <code>rdbuf()</code>. 179*03a78d15Sespie Then the public version of <code>setbuf</code> can be called. The 180*03a78d15Sespie arguments are the same as those for the Standard C I/O Library 181*03a78d15Sespie function (a buffer area followed by its size). 182*03a78d15Sespie </p> 183*03a78d15Sespie <p>A great deal of this is implementation-dependent. For example, 184*03a78d15Sespie <code>streambuf</code> does not specify any actions for its own 185*03a78d15Sespie <code>setbuf()</code>-ish functions; the classes derived from 186*03a78d15Sespie <code>streambuf</code> each define behavior that "makes 187*03a78d15Sespie sense" for that class: an argument of (0,0) turns off buffering 188*03a78d15Sespie for <code>filebuf</code> but has undefined behavior for its sibling 189*03a78d15Sespie <code>stringbuf</code>, and specifying anything other than (0,0) has 190*03a78d15Sespie varying effects. Other user-defined class derived from streambuf can 191*03a78d15Sespie do whatever they want. (For <code>filebuf</code> and arguments for 192*03a78d15Sespie <code>(p,s)</code> other than zeros, libstdc++ does what you'd expect: 193*03a78d15Sespie the first <code>s</code> bytes of <code>p</code> are used as a buffer, 194*03a78d15Sespie which you must allocate and deallocate.) 195*03a78d15Sespie </p> 196*03a78d15Sespie <p>A last reminder: there are usually more buffers involved than 197*03a78d15Sespie just those at the language/library level. Kernel buffers, disk 198*03a78d15Sespie buffers, and the like will also have an effect. Inspecting and 199*03a78d15Sespie changing those are system-dependent. 200*03a78d15Sespie </p> 201*03a78d15Sespie <p>Return <a href="#top">to top of page</a> or 202*03a78d15Sespie <a href="../faq/index.html">to the FAQ</a>. 203*03a78d15Sespie </p> 204*03a78d15Sespie 205*03a78d15Sespie<hr /> 206*03a78d15Sespie<h2><a name="3">Binary I/O</a></h2> 207*03a78d15Sespie <p>The first and most important thing to remember about binary I/O is 208*03a78d15Sespie that opening a file with <code>ios::binary</code> is not, repeat 209*03a78d15Sespie <em>not</em>, the only thing you have to do. It is not a silver 210*03a78d15Sespie bullet, and will not allow you to use the <code><</>></code> 211*03a78d15Sespie operators of the normal fstreams to do binary I/O. 212*03a78d15Sespie </p> 213*03a78d15Sespie <p>Sorry. Them's the breaks. 214*03a78d15Sespie </p> 215*03a78d15Sespie <p>This isn't going to try and be a complete tutorial on reading and 216*03a78d15Sespie writing binary files (because "binary" 217*03a78d15Sespie <a href="#7">covers a lot of ground)</a>, but we will try and clear 218*03a78d15Sespie up a couple of misconceptions and common errors. 219*03a78d15Sespie </p> 220*03a78d15Sespie <p>First, <code>ios::binary</code> has exactly one defined effect, no more 221*03a78d15Sespie and no less. Normal text mode has to be concerned with the newline 222*03a78d15Sespie characters, and the runtime system will translate between (for 223*03a78d15Sespie example) '\n' and the appropriate end-of-line sequence (LF on Unix, 224*03a78d15Sespie CRLF on DOS, CR on Macintosh, etc). (There are other things that 225*03a78d15Sespie normal mode does, but that's the most obvious.) Opening a file in 226*03a78d15Sespie binary mode disables this conversion, so reading a CRLF sequence 227*03a78d15Sespie under Windows won't accidentally get mapped to a '\n' character, etc. 228*03a78d15Sespie Binary mode is not supposed to suddenly give you a bitstream, and 229*03a78d15Sespie if it is doing so in your program then you've discovered a bug in 230*03a78d15Sespie your vendor's compiler (or some other part of the C++ implementation, 231*03a78d15Sespie possibly the runtime system). 232*03a78d15Sespie </p> 233*03a78d15Sespie <p>Second, using <code><<</code> to write and <code>>></code> to 234*03a78d15Sespie read isn't going to work with the standard file stream classes, even 235*03a78d15Sespie if you use <code>skipws</code> during reading. Why not? Because 236*03a78d15Sespie ifstream and ofstream exist for the purpose of <em>formatting</em>, 237*03a78d15Sespie not reading and writing. Their job is to interpret the data into 238*03a78d15Sespie text characters, and that's exactly what you don't want to happen 239*03a78d15Sespie during binary I/O. 240*03a78d15Sespie </p> 241*03a78d15Sespie <p>Third, using the <code>get()</code> and <code>put()/write()</code> member 242*03a78d15Sespie functions still aren't guaranteed to help you. These are 243*03a78d15Sespie "unformatted" I/O functions, but still character-based. 244*03a78d15Sespie (This may or may not be what you want, see below.) 245*03a78d15Sespie </p> 246*03a78d15Sespie <p>Notice how all the problems here are due to the inappropriate use 247*03a78d15Sespie of <em>formatting</em> functions and classes to perform something 248*03a78d15Sespie which <em>requires</em> that formatting not be done? There are a 249*03a78d15Sespie seemingly infinite number of solutions, and a few are listed here: 250*03a78d15Sespie </p> 251*03a78d15Sespie <ul> 252*03a78d15Sespie <li>"Derive your own fstream-type classes and write your own 253*03a78d15Sespie <</>> operators to do binary I/O on whatever data 254*03a78d15Sespie types you're using." This is a Bad Thing, because while 255*03a78d15Sespie the compiler would probably be just fine with it, other humans 256*03a78d15Sespie are going to be confused. The overloaded bitshift operators 257*03a78d15Sespie have a well-defined meaning (formatting), and this breaks it. 258*03a78d15Sespie </li> 259*03a78d15Sespie <li>"Build the file structure in memory, then <code>mmap()</code> 260*03a78d15Sespie the file and copy the structure." Well, this is easy to 261*03a78d15Sespie make work, and easy to break, and is pretty equivalent to 262*03a78d15Sespie using <code>::read()</code> and <code>::write()</code> directly, and 263*03a78d15Sespie makes no use of the iostream library at all... 264*03a78d15Sespie </li> 265*03a78d15Sespie <li>"Use streambufs, that's what they're there for." 266*03a78d15Sespie While not trivial for the beginner, this is the best of all 267*03a78d15Sespie solutions. The streambuf/filebuf layer is the layer that is 268*03a78d15Sespie responsible for actual I/O. If you want to use the C++ 269*03a78d15Sespie library for binary I/O, this is where you start. 270*03a78d15Sespie </li> 271*03a78d15Sespie </ul> 272*03a78d15Sespie <p>How to go about using streambufs is a bit beyond the scope of this 273*03a78d15Sespie document (at least for now), but while streambufs go a long way, 274*03a78d15Sespie they still leave a couple of things up to you, the programmer. 275*03a78d15Sespie As an example, byte ordering is completely between you and the 276*03a78d15Sespie operating system, and you have to handle it yourself. 277*03a78d15Sespie </p> 278*03a78d15Sespie <p>Deriving a streambuf or filebuf 279*03a78d15Sespie class from the standard ones, one that is specific to your data 280*03a78d15Sespie types (or an abstraction thereof) is probably a good idea, and 281*03a78d15Sespie lots of examples exist in journals and on Usenet. Using the 282*03a78d15Sespie standard filebufs directly (either by declaring your own or by 283*03a78d15Sespie using the pointer returned from an fstream's <code>rdbuf()</code>) 284*03a78d15Sespie is certainly feasible as well. 285*03a78d15Sespie </p> 286*03a78d15Sespie <p>One area that causes problems is trying to do bit-by-bit operations 287*03a78d15Sespie with filebufs. C++ is no different from C in this respect: I/O 288*03a78d15Sespie must be done at the byte level. If you're trying to read or write 289*03a78d15Sespie a few bits at a time, you're going about it the wrong way. You 290*03a78d15Sespie must read/write an integral number of bytes and then process the 291*03a78d15Sespie bytes. (For example, the streambuf functions take and return 292*03a78d15Sespie variables of type <code>int_type</code>.) 293*03a78d15Sespie </p> 294*03a78d15Sespie <p>Another area of problems is opening text files in binary mode. 295*03a78d15Sespie Generally, binary mode is intended for binary files, and opening 296*03a78d15Sespie text files in binary mode means that you now have to deal with all of 297*03a78d15Sespie those end-of-line and end-of-file problems that we mentioned before. 298*03a78d15Sespie An instructive thread from comp.lang.c++.moderated delved off into 299*03a78d15Sespie this topic starting more or less at 300*03a78d15Sespie <a href="http://www.deja.com/getdoc.xp?AN=436187505">this</a> 301*03a78d15Sespie article and continuing to the end of the thread. (You'll have to 302*03a78d15Sespie sort through some flames every couple of paragraphs, but the points 303*03a78d15Sespie made are good ones.) 304*03a78d15Sespie </p> 305*03a78d15Sespie 306*03a78d15Sespie<hr /> 307*03a78d15Sespie<h2><a name="5">What is this <sstream>/stringstreams thing?</a></h2> 308*03a78d15Sespie <p>Stringstreams (defined in the header <code><sstream></code>) 309*03a78d15Sespie are in this author's opinion one of the coolest things since 310*03a78d15Sespie sliced time. An example of their use is in the Received Wisdom 311*03a78d15Sespie section for Chapter 21 (Strings), 312*03a78d15Sespie <a href="../21_strings/howto.html#1.1internal"> describing how to 313*03a78d15Sespie format strings</a>. 314*03a78d15Sespie </p> 315*03a78d15Sespie <p>The quick definition is: they are siblings of ifstream and ofstream, 316*03a78d15Sespie and they do for <code>std::string</code> what their siblings do for 317*03a78d15Sespie files. All that work you put into writing <code><<</code> and 318*03a78d15Sespie <code>>></code> functions for your classes now pays off 319*03a78d15Sespie <em>again!</em> Need to format a string before passing the string 320*03a78d15Sespie to a function? Send your stuff via <code><<</code> to an 321*03a78d15Sespie ostringstream. You've read a string as input and need to parse it? 322*03a78d15Sespie Initialize an istringstream with that string, and then pull pieces 323*03a78d15Sespie out of it with <code>>></code>. Have a stringstream and need to 324*03a78d15Sespie get a copy of the string inside? Just call the <code>str()</code> 325*03a78d15Sespie member function. 326*03a78d15Sespie </p> 327*03a78d15Sespie <p>This only works if you've written your 328*03a78d15Sespie <code><<</code>/<code>>></code> functions correctly, though, 329*03a78d15Sespie and correctly means that they take istreams and ostreams as 330*03a78d15Sespie parameters, not i<b>f</b>streams and o<b>f</b>streams. If they 331*03a78d15Sespie take the latter, then your I/O operators will work fine with 332*03a78d15Sespie file streams, but with nothing else -- including stringstreams. 333*03a78d15Sespie </p> 334*03a78d15Sespie <p>If you are a user of the strstream classes, you need to update 335*03a78d15Sespie your code. You don't have to explicitly append <code>ends</code> to 336*03a78d15Sespie terminate the C-style character array, you don't have to mess with 337*03a78d15Sespie "freezing" functions, and you don't have to manage the 338*03a78d15Sespie memory yourself. The strstreams have been officially deprecated, 339*03a78d15Sespie which means that 1) future revisions of the C++ Standard won't 340*03a78d15Sespie support them, and 2) if you use them, people will laugh at you. 341*03a78d15Sespie </p> 342*03a78d15Sespie 343*03a78d15Sespie<hr /> 344*03a78d15Sespie<h2><a name="6">Deriving a stream buffer</a></h2> 345*03a78d15Sespie <p>Creating your own stream buffers for I/O can be remarkably easy. 346*03a78d15Sespie If you are interested in doing so, we highly recommend two very 347*03a78d15Sespie excellent books: 348*03a78d15Sespie <a href="http://home.camelot.de/langer/iostreams.htm">Standard C++ 349*03a78d15Sespie IOStreams and Locales</a> by Langer and Kreft, ISBN 0-201-18395-1, and 350*03a78d15Sespie <a href="http://www.josuttis.com/libbook/">The C++ Standard Library</a> 351*03a78d15Sespie by Nicolai Josuttis, ISBN 0-201-37926-0. Both are published by 352*03a78d15Sespie Addison-Wesley, who isn't paying us a cent for saying that, honest. 353*03a78d15Sespie </p> 354*03a78d15Sespie <p>Here is a simple example, io/outbuf1, from the Josuttis text. It 355*03a78d15Sespie transforms everything sent through it to uppercase. This version 356*03a78d15Sespie assumes many things about the nature of the character type being 357*03a78d15Sespie used (for more information, read the books or the newsgroups): 358*03a78d15Sespie </p> 359*03a78d15Sespie <pre> 360*03a78d15Sespie #include <iostream> 361*03a78d15Sespie #include <streambuf> 362*03a78d15Sespie #include <locale> 363*03a78d15Sespie #include <cstdio> 364*03a78d15Sespie 365*03a78d15Sespie class outbuf : public std::streambuf 366*03a78d15Sespie { 367*03a78d15Sespie protected: 368*03a78d15Sespie /* central output function 369*03a78d15Sespie * - print characters in uppercase mode 370*03a78d15Sespie */ 371*03a78d15Sespie virtual int_type overflow (int_type c) { 372*03a78d15Sespie if (c != EOF) { 373*03a78d15Sespie // convert lowercase to uppercase 374*03a78d15Sespie c = std::toupper(static_cast<char>(c),getloc()); 375*03a78d15Sespie 376*03a78d15Sespie // and write the character to the standard output 377*03a78d15Sespie if (putchar(c) == EOF) { 378*03a78d15Sespie return EOF; 379*03a78d15Sespie } 380*03a78d15Sespie } 381*03a78d15Sespie return c; 382*03a78d15Sespie } 383*03a78d15Sespie }; 384*03a78d15Sespie 385*03a78d15Sespie int main() 386*03a78d15Sespie { 387*03a78d15Sespie // create special output buffer 388*03a78d15Sespie outbuf ob; 389*03a78d15Sespie // initialize output stream with that output buffer 390*03a78d15Sespie std::ostream out(&ob); 391*03a78d15Sespie 392*03a78d15Sespie out << "31 hexadecimal: " 393*03a78d15Sespie << std::hex << 31 << std::endl; 394*03a78d15Sespie return 0; 395*03a78d15Sespie } 396*03a78d15Sespie </pre> 397*03a78d15Sespie <p>Try it yourself! More examples can be found in 3.1.x code, in 398*03a78d15Sespie <code>include/ext/*_filebuf.h</code>, and on 399*03a78d15Sespie <a href="http://www.informatik.uni-konstanz.de/~kuehl/c++/iostream/">Dietmar 400*03a78d15Sespie Kühl's IOStreams page</a>. 401*03a78d15Sespie </p> 402*03a78d15Sespie 403*03a78d15Sespie<hr /> 404*03a78d15Sespie<h2><a name="7">More on binary I/O</a></h2> 405*03a78d15Sespie <p>Towards the beginning of February 2001, the subject of 406*03a78d15Sespie "binary" I/O was brought up in a couple of places at the 407*03a78d15Sespie same time. One notable place was Usenet, where James Kanze and 408*03a78d15Sespie Dietmar Kühl separately posted articles on why attempting 409*03a78d15Sespie generic binary I/O was not a good idea. (Here are copies of 410*03a78d15Sespie <a href="binary_iostreams_kanze.txt">Kanze's article</a> and 411*03a78d15Sespie <a href="binary_iostreams_kuehl.txt">Kühl's article</a>.) 412*03a78d15Sespie </p> 413*03a78d15Sespie <p>Briefly, the problems of byte ordering and type sizes mean that 414*03a78d15Sespie the unformatted functions like <code>ostream::put()</code> and 415*03a78d15Sespie <code>istream::get()</code> cannot safely be used to communicate 416*03a78d15Sespie between arbitrary programs, or across a network, or from one 417*03a78d15Sespie invocation of a program to another invocation of the same program 418*03a78d15Sespie on a different platform, etc. 419*03a78d15Sespie </p> 420*03a78d15Sespie <p>The entire Usenet thread is instructive, and took place under the 421*03a78d15Sespie subject heading "binary iostreams" on both comp.std.c++ 422*03a78d15Sespie and comp.lang.c++.moderated in parallel. Also in that thread, 423*03a78d15Sespie Dietmar Kühl mentioned that he had written a pair of stream 424*03a78d15Sespie classes that would read and write XDR, which is a good step towards 425*03a78d15Sespie a portable binary format. 426*03a78d15Sespie </p> 427*03a78d15Sespie 428*03a78d15Sespie<hr /> 429*03a78d15Sespie<h2><a name="8">Pathetic performance? Ditch C.</a></h2> 430*03a78d15Sespie <p>It sounds like a flame on C, but it isn't. Really. Calm down. 431*03a78d15Sespie I'm just saying it to get your attention. 432*03a78d15Sespie </p> 433*03a78d15Sespie <p>Because the C++ library includes the C library, both C-style and 434*03a78d15Sespie C++-style I/O have to work at the same time. For example: 435*03a78d15Sespie </p> 436*03a78d15Sespie <pre> 437*03a78d15Sespie #include <iostream> 438*03a78d15Sespie #include <cstdio> 439*03a78d15Sespie 440*03a78d15Sespie std::cout << "Hel"; 441*03a78d15Sespie std::printf ("lo, worl"); 442*03a78d15Sespie std::cout << "d!\n"; 443*03a78d15Sespie </pre> 444*03a78d15Sespie <p>This must do what you think it does. 445*03a78d15Sespie </p> 446*03a78d15Sespie <p>Alert members of the audience will immediately notice that buffering 447*03a78d15Sespie is going to make a hash of the output unless special steps are taken. 448*03a78d15Sespie </p> 449*03a78d15Sespie <p>The special steps taken by libstdc++, at least for version 3.0, 450*03a78d15Sespie involve doing very little buffering for the standard streams, leaving 451*03a78d15Sespie most of the buffering to the underlying C library. (This kind of 452*03a78d15Sespie thing is <a href="../explanations.html#cstdio">tricky to get right</a>.) 453*03a78d15Sespie The upside is that correctness is ensured. The downside is that 454*03a78d15Sespie writing through <code>cout</code> can quite easily lead to awful 455*03a78d15Sespie performance when the C++ I/O library is layered on top of the C I/O 456*03a78d15Sespie library (as it is for 3.0 by default). Some patches have been applied 457*03a78d15Sespie which improve the situation for 3.1. 458*03a78d15Sespie </p> 459*03a78d15Sespie <p>However, the C and C++ standard streams only need to be kept in sync 460*03a78d15Sespie when both libraries' facilities are in use. If your program only uses 461*03a78d15Sespie C++ I/O, then there's no need to sync with the C streams. The right 462*03a78d15Sespie thing to do in this case is to call 463*03a78d15Sespie </p> 464*03a78d15Sespie <pre> 465*03a78d15Sespie #include <em>any of the I/O headers such as ios, iostream, etc</em> 466*03a78d15Sespie 467*03a78d15Sespie std::ios::sync_with_stdio(false); 468*03a78d15Sespie </pre> 469*03a78d15Sespie <p>You must do this before performing any I/O via the C++ stream objects. 470*03a78d15Sespie Once you call this, the C++ streams will operate independently of the 471*03a78d15Sespie (unused) C streams. For GCC 3.x, this means that <code>cout</code> and 472*03a78d15Sespie company will become fully buffered on their own. 473*03a78d15Sespie </p> 474*03a78d15Sespie <p>Note, by the way, that the synchronization requirement only applies to 475*03a78d15Sespie the standard streams (<code>cin</code>, <code>cout</code>, 476*03a78d15Sespie <code>cerr</code>, 477*03a78d15Sespie <code>clog</code>, and their wide-character counterparts). File stream 478*03a78d15Sespie objects that you declare yourself have no such requirement and are fully 479*03a78d15Sespie buffered. 480*03a78d15Sespie </p> 481*03a78d15Sespie 482*03a78d15Sespie<hr /> 483*03a78d15Sespie<h2><a name="9">Threads and I/O</a></h2> 484*03a78d15Sespie <p>I'll assume that you have already read the 485*03a78d15Sespie <a href="../17_intro/howto.html#3">general notes on library threads</a>, 486*03a78d15Sespie and the 487*03a78d15Sespie <a href="../23_containers/howto.html#3">notes on threaded container 488*03a78d15Sespie access</a> (you might not think of an I/O stream as a container, but 489*03a78d15Sespie the points made there also hold here). If you have not read them, 490*03a78d15Sespie please do so first. 491*03a78d15Sespie </p> 492*03a78d15Sespie <p>This gets a bit tricky. Please read carefully, and bear with me. 493*03a78d15Sespie </p> 494*03a78d15Sespie <h3>Structure</h3> 495*03a78d15Sespie <p>As described <a href="../explanations.html#cstdio">here</a>, a wrapper 496*03a78d15Sespie type called <code>__basic_file</code> provides our abstraction layer 497*03a78d15Sespie for the <code>std::filebuf</code> classes. Nearly all decisions dealing 498*03a78d15Sespie with actual input and output must be made in <code>__basic_file</code>. 499*03a78d15Sespie </p> 500*03a78d15Sespie <p>A generic locking mechanism is somewhat in place at the filebuf layer, 501*03a78d15Sespie but is not used in the current code. Providing locking at any higher 502*03a78d15Sespie level is akin to providing locking within containers, and is not done 503*03a78d15Sespie for the same reasons (see the links above). 504*03a78d15Sespie </p> 505*03a78d15Sespie <h3>The defaults for 3.0.x</h3> 506*03a78d15Sespie <p>The __basic_file type is simply a collection of small wrappers around 507*03a78d15Sespie the C stdio layer (again, see the link under Structure). We do no 508*03a78d15Sespie locking ourselves, but simply pass through to calls to <code>fopen</code>, 509*03a78d15Sespie <code>fwrite</code>, and so forth. 510*03a78d15Sespie </p> 511*03a78d15Sespie <p>So, for 3.0, the question of "is multithreading safe for I/O" 512*03a78d15Sespie must be answered with, "is your platform's C library threadsafe 513*03a78d15Sespie for I/O?" Some are by default, some are not; many offer multiple 514*03a78d15Sespie implementations of the C library with varying tradeoffs of threadsafety 515*03a78d15Sespie and efficiency. You, the programmer, are always required to take care 516*03a78d15Sespie with multiple threads. 517*03a78d15Sespie </p> 518*03a78d15Sespie <p>(As an example, the POSIX standard requires that C stdio FILE* 519*03a78d15Sespie operations are atomic. POSIX-conforming C libraries (e.g, on Solaris 520*03a78d15Sespie and GNU/Linux) have an internal mutex to serialize operations on 521*03a78d15Sespie FILE*s. However, you still need to not do stupid things like calling 522*03a78d15Sespie <code>fclose(fs)</code> in one thread followed by an access of 523*03a78d15Sespie <code>fs</code> in another.) 524*03a78d15Sespie </p> 525*03a78d15Sespie <p>So, if your platform's C library is threadsafe, then your 526*03a78d15Sespie <code>fstream</code> I/O operations will be threadsafe at the lowest 527*03a78d15Sespie level. For higher-level operations, such as manipulating the data 528*03a78d15Sespie contained in the stream formatting classes (e.g., setting up callbacks 529*03a78d15Sespie inside an <code>std::ofstream</code>), you need to guard such accesses 530*03a78d15Sespie like any other critical shared resource. 531*03a78d15Sespie </p> 532*03a78d15Sespie <h3>The future</h3> 533*03a78d15Sespie <p>As already mentioned <a href="../explanations.html#cstdio">here</a>, a 534*03a78d15Sespie second choice is available for I/O implementations: libio. This is 535*03a78d15Sespie disabled by default, and in fact will not currently work due to other 536*03a78d15Sespie issues. It will be revisited, however. 537*03a78d15Sespie </p> 538*03a78d15Sespie <p>The libio code is a subset of the guts of the GNU libc (glibc) I/O 539*03a78d15Sespie implementation. When libio is in use, the <code>__basic_file</code> 540*03a78d15Sespie type is basically derived from FILE. (The real situation is more 541*03a78d15Sespie complex than that... it's derived from an internal type used to 542*03a78d15Sespie implement FILE. See libio/libioP.h to see scary things done with 543*03a78d15Sespie vtbls.) The result is that there is no "layer" of C stdio 544*03a78d15Sespie to go through; the filebuf makes calls directly into the same 545*03a78d15Sespie functions used to implement <code>fread</code>, <code>fwrite</code>, 546*03a78d15Sespie and so forth, using internal data structures. (And when I say 547*03a78d15Sespie "makes calls directly," I mean the function is literally 548*03a78d15Sespie replaced by a jump into an internal function. Fast but frightening. 549*03a78d15Sespie *grin*) 550*03a78d15Sespie </p> 551*03a78d15Sespie <p>Also, the libio internal locks are used. This requires pulling in 552*03a78d15Sespie large chunks of glibc, such as a pthreads implementation, and is one 553*03a78d15Sespie of the issues preventing widespread use of libio as the libstdc++ 554*03a78d15Sespie cstdio implementation. 555*03a78d15Sespie </p> 556*03a78d15Sespie <p>But we plan to make this work, at least as an option if not a future 557*03a78d15Sespie default. Platforms running a copy of glibc with a recent-enough 558*03a78d15Sespie version will see calls from libstdc++ directly into the glibc already 559*03a78d15Sespie installed. For other platforms, a copy of the libio subsection will 560*03a78d15Sespie be built and included in libstdc++. 561*03a78d15Sespie </p> 562*03a78d15Sespie <h3>Alternatives</h3> 563*03a78d15Sespie <p>Don't forget that other cstdio implemenations are possible. You could 564*03a78d15Sespie easily write one to perform your own forms of locking, to solve your 565*03a78d15Sespie "interesting" problems. 566*03a78d15Sespie </p> 567*03a78d15Sespie 568*03a78d15Sespie<hr /> 569*03a78d15Sespie<h2><a name="10">Which header?</a></h2> 570*03a78d15Sespie <p>To minimize the time you have to wait on the compiler, it's good to 571*03a78d15Sespie only include the headers you really need. Many people simply include 572*03a78d15Sespie <iostream> when they don't need to -- and that can <em>penalize 573*03a78d15Sespie your runtime as well.</em> Here are some tips on which header to use 574*03a78d15Sespie for which situations, starting with the simplest. 575*03a78d15Sespie </p> 576*03a78d15Sespie <p><strong><iosfwd></strong> should be included whenever you simply 577*03a78d15Sespie need the <em>name</em> of an I/O-related class, such as 578*03a78d15Sespie "ofstream" or "basic_streambuf". Like the name 579*03a78d15Sespie implies, these are forward declarations. (A word to all you fellow 580*03a78d15Sespie old school programmers: trying to forward declare classes like 581*03a78d15Sespie "class istream;" won't work. Look in the iosfwd header if 582*03a78d15Sespie you'd like to know why.) For example, 583*03a78d15Sespie </p> 584*03a78d15Sespie <pre> 585*03a78d15Sespie #include <iosfwd> 586*03a78d15Sespie 587*03a78d15Sespie class MyClass 588*03a78d15Sespie { 589*03a78d15Sespie .... 590*03a78d15Sespie std::ifstream input_file; 591*03a78d15Sespie }; 592*03a78d15Sespie 593*03a78d15Sespie extern std::ostream& operator<< (std::ostream&, MyClass&); 594*03a78d15Sespie </pre> 595*03a78d15Sespie <p><strong><ios></strong> declares the base classes for the entire 596*03a78d15Sespie I/O stream hierarchy, std::ios_base and std::basic_ios<charT>, the 597*03a78d15Sespie counting types std::streamoff and std::streamsize, the file 598*03a78d15Sespie positioning type std::fpos, and the various manipulators like 599*03a78d15Sespie std::hex, std::fixed, std::noshowbase, and so forth. 600*03a78d15Sespie </p> 601*03a78d15Sespie <p>The ios_base class is what holds the format flags, the state flags, 602*03a78d15Sespie and the functions which change them (setf(), width(), precision(), 603*03a78d15Sespie etc). You can also store extra data and register callback functions 604*03a78d15Sespie through ios_base, but that has been historically underused. Anything 605*03a78d15Sespie which doesn't depend on the type of characters stored is consolidated 606*03a78d15Sespie here. 607*03a78d15Sespie </p> 608*03a78d15Sespie <p>The template class basic_ios is the highest template class in the 609*03a78d15Sespie hierarchy; it is the first one depending on the character type, and 610*03a78d15Sespie holds all general state associated with that type: the pointer to the 611*03a78d15Sespie polymorphic stream buffer, the facet information, etc. 612*03a78d15Sespie </p> 613*03a78d15Sespie <p><strong><streambuf></strong> declares the template class 614*03a78d15Sespie basic_streambuf, and two standard instantiations, streambuf and 615*03a78d15Sespie wstreambuf. If you need to work with the vastly useful and capable 616*03a78d15Sespie stream buffer classes, e.g., to create a new form of storage 617*03a78d15Sespie transport, this header is the one to include. 618*03a78d15Sespie </p> 619*03a78d15Sespie <p><strong><istream></strong>/<strong><ostream></strong> are 620*03a78d15Sespie the headers to include when you are using the >>/<< 621*03a78d15Sespie interface, or any of the other abstract stream formatting functions. 622*03a78d15Sespie For example, 623*03a78d15Sespie </p> 624*03a78d15Sespie <pre> 625*03a78d15Sespie #include <istream> 626*03a78d15Sespie 627*03a78d15Sespie std::ostream& operator<< (std::ostream& os, MyClass& c) 628*03a78d15Sespie { 629*03a78d15Sespie return os << c.data1() << c.data2(); 630*03a78d15Sespie } 631*03a78d15Sespie </pre> 632*03a78d15Sespie <p>The std::istream and std::ostream classes are the abstract parents of 633*03a78d15Sespie the various concrete implementations. If you are only using the 634*03a78d15Sespie interfaces, then you only need to use the appropriate interface header. 635*03a78d15Sespie </p> 636*03a78d15Sespie <p><strong><iomanip></strong> provides "extractors and inserters 637*03a78d15Sespie that alter information maintained by class ios_base and its dervied 638*03a78d15Sespie classes," such as std::setprecision and std::setw. If you need 639*03a78d15Sespie to write expressions like <code>os << setw(3);</code> or 640*03a78d15Sespie <code>is >> setbase(8);</code>, you must include <iomanip>. 641*03a78d15Sespie </p> 642*03a78d15Sespie <p><strong><sstream></strong>/<strong><fstream></strong> 643*03a78d15Sespie declare the six stringstream and fstream classes. As they are the 644*03a78d15Sespie standard concrete descendants of istream and ostream, you will already 645*03a78d15Sespie know about them. 646*03a78d15Sespie </p> 647*03a78d15Sespie <p>Finally, <strong><iostream></strong> provides the eight standard 648*03a78d15Sespie global objects (cin, cout, etc). To do this correctly, this header 649*03a78d15Sespie also provides the contents of the <istream> and <ostream> 650*03a78d15Sespie headers, but nothing else. The contents of this header look like 651*03a78d15Sespie </p> 652*03a78d15Sespie <pre> 653*03a78d15Sespie #include <ostream> 654*03a78d15Sespie #include <istream> 655*03a78d15Sespie 656*03a78d15Sespie namespace std 657*03a78d15Sespie { 658*03a78d15Sespie extern istream cin; 659*03a78d15Sespie extern ostream cout; 660*03a78d15Sespie .... 661*03a78d15Sespie 662*03a78d15Sespie // this is explained below 663*03a78d15Sespie <strong>static ios_base::Init __foo;</strong> // not its real name 664*03a78d15Sespie } 665*03a78d15Sespie </pre> 666*03a78d15Sespie <p>Now, the runtime penalty mentioned previously: the global objects 667*03a78d15Sespie must be initialized before any of your own code uses them; this is 668*03a78d15Sespie guaranteed by the standard. Like any other global object, they must 669*03a78d15Sespie be initialized once and only once. This is typically done with a 670*03a78d15Sespie construct like the one above, and the nested class ios_base::Init is 671*03a78d15Sespie specified in the standard for just this reason. 672*03a78d15Sespie </p> 673*03a78d15Sespie <p>How does it work? Because the header is included before any of your 674*03a78d15Sespie code, the <strong>__foo</strong> object is constructed before any of 675*03a78d15Sespie your objects. (Global objects are built in the order in which they 676*03a78d15Sespie are declared, and destroyed in reverse order.) The first time the 677*03a78d15Sespie constructor runs, the eight stream objects are set up. 678*03a78d15Sespie </p> 679*03a78d15Sespie <p>The <code>static</code> keyword means that each object file compiled 680*03a78d15Sespie from a source file containing <iostream> will have its own 681*03a78d15Sespie private copy of <strong>__foo</strong>. There is no specified order 682*03a78d15Sespie of construction across object files (it's one of those pesky NP 683*03a78d15Sespie problems that make life so interesting), so one copy in each object 684*03a78d15Sespie file means that the stream objects are guaranteed to be set up before 685*03a78d15Sespie any of your code which uses them could run, thereby meeting the 686*03a78d15Sespie requirements of the standard. 687*03a78d15Sespie </p> 688*03a78d15Sespie <p>The penalty, of course, is that after the first copy of 689*03a78d15Sespie <strong>__foo</strong> is constructed, all the others are just wasted 690*03a78d15Sespie processor time. The time spent is merely for an increment-and-test 691*03a78d15Sespie inside a function call, but over several dozen or hundreds of object 692*03a78d15Sespie files, that time can add up. (It's not in a tight loop, either.) 693*03a78d15Sespie </p> 694*03a78d15Sespie <p>The lesson? Only include <iostream> when you need to use one of 695*03a78d15Sespie the standard objects in that source file; you'll pay less startup 696*03a78d15Sespie time. Only include the header files you need to in general; your 697*03a78d15Sespie compile times will go down when there's less parsing work to do. 698*03a78d15Sespie </p> 699*03a78d15Sespie 700*03a78d15Sespie 701*03a78d15Sespie<hr /> 702*03a78d15Sespie<h2><a name="11">Using FILE*s and file descriptors with IOStreams</a></h2> 703*03a78d15Sespie <!-- referenced by ext/howto.html#2, update link if numbering changes --> 704*03a78d15Sespie <p>The v2 library included non-standard extensions to construct 705*03a78d15Sespie <code>std::filebuf</code>s from C stdio types such as 706*03a78d15Sespie <code>FILE*</code>s and POSIX file descriptors. 707*03a78d15Sespie Today the recommended way to use stdio types with libstdc++-v3 708*03a78d15Sespie IOStreams is via the <code>stdio_filebuf</code> class (see below), 709*03a78d15Sespie but earlier releases provided slightly different mechanisms. 710*03a78d15Sespie </p> 711*03a78d15Sespie <ul> 712*03a78d15Sespie <li>3.0.x <code>filebuf</code>s have another ctor with this signature: 713*03a78d15Sespie <br /> 714*03a78d15Sespie <code>basic_filebuf(__c_file_type*, ios_base::openmode, int_type);</code> 715*03a78d15Sespie <br />This comes in very handy in a number of places, such as 716*03a78d15Sespie attaching Unix sockets, pipes, and anything else which uses file 717*03a78d15Sespie descriptors, into the IOStream buffering classes. The three 718*03a78d15Sespie arguments are as follows: 719*03a78d15Sespie <ul> 720*03a78d15Sespie <li><code>__c_file_type* F </code> 721*03a78d15Sespie // the __c_file_type typedef usually boils down to stdio's FILE 722*03a78d15Sespie </li> 723*03a78d15Sespie <li><code>ios_base::openmode M </code> 724*03a78d15Sespie // same as all the other uses of openmode 725*03a78d15Sespie </li> 726*03a78d15Sespie <li><code>int_type B </code> 727*03a78d15Sespie // buffer size, defaults to BUFSIZ if not specified 728*03a78d15Sespie </li> 729*03a78d15Sespie </ul> 730*03a78d15Sespie For those wanting to use file descriptors instead of FILE*'s, I 731*03a78d15Sespie invite you to contemplate the mysteries of C's <code>fdopen()</code>. 732*03a78d15Sespie </li> 733*03a78d15Sespie <li>In library snapshot 3.0.95 and later, <code>filebuf</code>s bring 734*03a78d15Sespie back an old extension: the <code>fd()</code> member function. The 735*03a78d15Sespie integer returned from this function can be used for whatever file 736*03a78d15Sespie descriptors can be used for on your platform. Naturally, the 737*03a78d15Sespie library cannot track what you do on your own with a file descriptor, 738*03a78d15Sespie so if you perform any I/O directly, don't expect the library to be 739*03a78d15Sespie aware of it. 740*03a78d15Sespie </li> 741*03a78d15Sespie <li>Beginning with 3.1, the extra <code>filebuf</code> constructor and 742*03a78d15Sespie the <code>fd()</code> function were removed from the standard 743*03a78d15Sespie filebuf. Instead, <code><ext/stdio_filebuf.h></code> contains 744*03a78d15Sespie a derived class called 745*03a78d15Sespie <a href="http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/class____gnu__cxx_1_1stdio__filebuf.html"><code>__gnu_cxx::stdio_filebuf</code></a>. 746*03a78d15Sespie This class can be constructed from a C <code>FILE*</code> or a file 747*03a78d15Sespie descriptor, and provides the <code>fd()</code> function. 748*03a78d15Sespie </li> 749*03a78d15Sespie </ul> 750*03a78d15Sespie <p>If you want to access a <code>filebuf</code>s file descriptor to 751*03a78d15Sespie implement file locking (e.g. using the <code>fcntl()</code> system 752*03a78d15Sespie call) then you might be interested in Henry Suter's 753*03a78d15Sespie <a href="http://suter.home.cern.ch/suter/RWLock.html">RWLock</a> 754*03a78d15Sespie class. 755*03a78d15Sespie </p> 756*03a78d15Sespie 757*03a78d15Sespie<!-- ####################################################### --> 758*03a78d15Sespie 759*03a78d15Sespie<hr /> 760*03a78d15Sespie<p class="fineprint"><em> 761*03a78d15SespieSee <a href="../17_intro/license.html">license.html</a> for copying conditions. 762*03a78d15SespieComments and suggestions are welcome, and may be sent to 763*03a78d15Sespie<a href="mailto:libstdc++@gcc.gnu.org">the libstdc++ mailing list</a>. 764*03a78d15Sespie</em></p> 765*03a78d15Sespie 766*03a78d15Sespie 767*03a78d15Sespie</body> 768*03a78d15Sespie</html> 769*03a78d15Sespie 770*03a78d15Sespie 771