| 1 |
424 |
jeremybenn |
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
| 2 |
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
| 3 |
|
|
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 24. Iostream Objects</title><meta name="generator" content="DocBook XSL Stylesheets V1.75.2" /><meta name="keywords" content=" ISO C++ , library " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="io.html" title="Part XI. Input and Output" /><link rel="prev" href="io.html" title="Part XI. Input and Output" /><link rel="next" href="streambufs.html" title="Chapter 25. Stream Buffers" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 24. Iostream Objects</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="io.html">Prev</a> </td><th width="60%" align="center">Part XI.
|
| 4 |
|
|
Input and Output
|
| 5 |
|
|
|
| 6 |
|
|
</th><td width="20%" align="right"> <a accesskey="n" href="streambufs.html">Next</a></td></tr></table><hr /></div><div class="chapter" title="Chapter 24. Iostream Objects"><div class="titlepage"><div><div><h2 class="title"><a id="manual.io.objects"></a>Chapter 24. Iostream Objects</h2></div></div></div><p>To minimize the time you have to wait on the compiler, it's good to
|
| 7 |
|
|
only include the headers you really need. Many people simply include
|
| 8 |
|
|
<iostream> when they don't need to -- and that can <span class="emphasis"><em>penalize
|
| 9 |
|
|
your runtime as well.</em></span> Here are some tips on which header to use
|
| 10 |
|
|
for which situations, starting with the simplest.
|
| 11 |
|
|
</p><p><span class="emphasis"><em><iosfwd></em></span> should be included whenever you simply
|
| 12 |
|
|
need the <span class="emphasis"><em>name</em></span> of an I/O-related class, such as
|
| 13 |
|
|
"ofstream" or "basic_streambuf". Like the name
|
| 14 |
|
|
implies, these are forward declarations. (A word to all you fellow
|
| 15 |
|
|
old school programmers: trying to forward declare classes like
|
| 16 |
|
|
"class istream;" won't work. Look in the iosfwd header if
|
| 17 |
|
|
you'd like to know why.) For example,
|
| 18 |
|
|
</p><pre class="programlisting">
|
| 19 |
|
|
#include <iosfwd>
|
| 20 |
|
|
|
| 21 |
|
|
class MyClass
|
| 22 |
|
|
{
|
| 23 |
|
|
....
|
| 24 |
|
|
std::ifstream& input_file;
|
| 25 |
|
|
};
|
| 26 |
|
|
|
| 27 |
|
|
extern std::ostream& operator<< (std::ostream&, MyClass&);
|
| 28 |
|
|
</pre><p><span class="emphasis"><em><ios></em></span> declares the base classes for the entire
|
| 29 |
|
|
I/O stream hierarchy, std::ios_base and std::basic_ios<charT>, the
|
| 30 |
|
|
counting types std::streamoff and std::streamsize, the file
|
| 31 |
|
|
positioning type std::fpos, and the various manipulators like
|
| 32 |
|
|
std::hex, std::fixed, std::noshowbase, and so forth.
|
| 33 |
|
|
</p><p>The ios_base class is what holds the format flags, the state flags,
|
| 34 |
|
|
and the functions which change them (setf(), width(), precision(),
|
| 35 |
|
|
etc). You can also store extra data and register callback functions
|
| 36 |
|
|
through ios_base, but that has been historically underused. Anything
|
| 37 |
|
|
which doesn't depend on the type of characters stored is consolidated
|
| 38 |
|
|
here.
|
| 39 |
|
|
</p><p>The template class basic_ios is the highest template class in the
|
| 40 |
|
|
hierarchy; it is the first one depending on the character type, and
|
| 41 |
|
|
holds all general state associated with that type: the pointer to the
|
| 42 |
|
|
polymorphic stream buffer, the facet information, etc.
|
| 43 |
|
|
</p><p><span class="emphasis"><em><streambuf></em></span> declares the template class
|
| 44 |
|
|
basic_streambuf, and two standard instantiations, streambuf and
|
| 45 |
|
|
wstreambuf. If you need to work with the vastly useful and capable
|
| 46 |
|
|
stream buffer classes, e.g., to create a new form of storage
|
| 47 |
|
|
transport, this header is the one to include.
|
| 48 |
|
|
</p><p><span class="emphasis"><em><istream></em></span>/<span class="emphasis"><em><ostream></em></span> are
|
| 49 |
|
|
the headers to include when you are using the >>/<<
|
| 50 |
|
|
interface, or any of the other abstract stream formatting functions.
|
| 51 |
|
|
For example,
|
| 52 |
|
|
</p><pre class="programlisting">
|
| 53 |
|
|
#include <istream>
|
| 54 |
|
|
|
| 55 |
|
|
std::ostream& operator<< (std::ostream& os, MyClass& c)
|
| 56 |
|
|
{
|
| 57 |
|
|
return os << c.data1() << c.data2();
|
| 58 |
|
|
}
|
| 59 |
|
|
</pre><p>The std::istream and std::ostream classes are the abstract parents of
|
| 60 |
|
|
the various concrete implementations. If you are only using the
|
| 61 |
|
|
interfaces, then you only need to use the appropriate interface header.
|
| 62 |
|
|
</p><p><span class="emphasis"><em><iomanip></em></span> provides "extractors and inserters
|
| 63 |
|
|
that alter information maintained by class ios_base and its derived
|
| 64 |
|
|
classes," such as std::setprecision and std::setw. If you need
|
| 65 |
|
|
to write expressions like <code class="code">os << setw(3);</code> or
|
| 66 |
|
|
<code class="code">is >> setbase(8);</code>, you must include <iomanip>.
|
| 67 |
|
|
</p><p><span class="emphasis"><em><sstream></em></span>/<span class="emphasis"><em><fstream></em></span>
|
| 68 |
|
|
declare the six stringstream and fstream classes. As they are the
|
| 69 |
|
|
standard concrete descendants of istream and ostream, you will already
|
| 70 |
|
|
know about them.
|
| 71 |
|
|
</p><p>Finally, <span class="emphasis"><em><iostream></em></span> provides the eight standard
|
| 72 |
|
|
global objects (cin, cout, etc). To do this correctly, this header
|
| 73 |
|
|
also provides the contents of the <istream> and <ostream>
|
| 74 |
|
|
headers, but nothing else. The contents of this header look like
|
| 75 |
|
|
</p><pre class="programlisting">
|
| 76 |
|
|
#include <ostream>
|
| 77 |
|
|
#include <istream>
|
| 78 |
|
|
|
| 79 |
|
|
namespace std
|
| 80 |
|
|
{
|
| 81 |
|
|
extern istream cin;
|
| 82 |
|
|
extern ostream cout;
|
| 83 |
|
|
....
|
| 84 |
|
|
|
| 85 |
|
|
// this is explained below
|
| 86 |
|
|
<span class="emphasis"><em>static ios_base::Init __foo;</em></span> // not its real name
|
| 87 |
|
|
}
|
| 88 |
|
|
</pre><p>Now, the runtime penalty mentioned previously: the global objects
|
| 89 |
|
|
must be initialized before any of your own code uses them; this is
|
| 90 |
|
|
guaranteed by the standard. Like any other global object, they must
|
| 91 |
|
|
be initialized once and only once. This is typically done with a
|
| 92 |
|
|
construct like the one above, and the nested class ios_base::Init is
|
| 93 |
|
|
specified in the standard for just this reason.
|
| 94 |
|
|
</p><p>How does it work? Because the header is included before any of your
|
| 95 |
|
|
code, the <span class="emphasis"><em>__foo</em></span> object is constructed before any of
|
| 96 |
|
|
your objects. (Global objects are built in the order in which they
|
| 97 |
|
|
are declared, and destroyed in reverse order.) The first time the
|
| 98 |
|
|
constructor runs, the eight stream objects are set up.
|
| 99 |
|
|
</p><p>The <code class="code">static</code> keyword means that each object file compiled
|
| 100 |
|
|
from a source file containing <iostream> will have its own
|
| 101 |
|
|
private copy of <span class="emphasis"><em>__foo</em></span>. There is no specified order
|
| 102 |
|
|
of construction across object files (it's one of those pesky NP
|
| 103 |
|
|
problems that make life so interesting), so one copy in each object
|
| 104 |
|
|
file means that the stream objects are guaranteed to be set up before
|
| 105 |
|
|
any of your code which uses them could run, thereby meeting the
|
| 106 |
|
|
requirements of the standard.
|
| 107 |
|
|
</p><p>The penalty, of course, is that after the first copy of
|
| 108 |
|
|
<span class="emphasis"><em>__foo</em></span> is constructed, all the others are just wasted
|
| 109 |
|
|
processor time. The time spent is merely for an increment-and-test
|
| 110 |
|
|
inside a function call, but over several dozen or hundreds of object
|
| 111 |
|
|
files, that time can add up. (It's not in a tight loop, either.)
|
| 112 |
|
|
</p><p>The lesson? Only include <iostream> when you need to use one of
|
| 113 |
|
|
the standard objects in that source file; you'll pay less startup
|
| 114 |
|
|
time. Only include the header files you need to in general; your
|
| 115 |
|
|
compile times will go down when there's less parsing work to do.
|
| 116 |
|
|
</p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="io.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="streambufs.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Part XI.
|
| 117 |
|
|
Input and Output
|
| 118 |
|
|
|
| 119 |
|
|
</td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 25. Stream Buffers</td></tr></table></div></body></html>
|
