• cin, to control the unbuffered standard input stream (as does stdin)
• cout, to control the unbuffered standard output stream (as does stdout)
• cerr, to control the unbuffered standard error stream (as does stderr)
• clog, to control the buffered standard error stream (as does stderr)

The header <iostream> is in many ways the culmination of all the iostreams machinery that I have described over the past year or so. Historically, in fact, the header <iostream.h> includes everything represented here in the headers <ios>, <streambuf>, <istream>, <ostream>, and <iostream>. The general assumption has been that, if you want to work with any part of iostreams, you certainly want to declare cin and friends as well.

Pulling it off takes a bit of trickery, however. Consider the problem. Unless the Standard C++ library indulges in some extra-linguistic magic, <iostream> must contain declarations something like:

extern istream cin;
extern ostream cout;
extern ostream cerr;
extern ostream clog

Fortunately, the language does define the ordering of constructor calls within a given object module. It promises to construct objects in the order in which they appear in the translation unit that defines the object module. You can't define cin early in each translation unit — exactly one instance of the object must occur throughout the entire program. But you can define something early enough to give you a fighting chance.

static ios::Init_Ios_init;

So far so good. A mechanism exists to get control in time. Presumably, it can ensure that cin and friends are properly constructed. For that, you can use a placement new expression. (See "Standard C: C++ Language Support Library," CUJ, March 1994.) Say, for example, you want to construct cin with the single-argument constructor that specifies a pointer to the stream buffer fin. You can then write:

 new (&cin) istream(&fin);

 istream cin(&fin);

• Say the definition occurs first. If it does anything nontrivial — such as allocating storage and storing a pointer to it in the constructed object — the placement new is going to stomp all over the result. This is bad hygiene.
• Say the placement new expression occurs first. If the definition later stores much anything at all in the object, it will mess up the effect of the placement new. This is disastrous.

The final trick is to avoid constructing cin and friends too many times. It's bad enough to have to double construct so many important objects within the iostreams package. You certainly don't want to construct them all once for each translation unit in a program that includes <iostream>. Class ios::Init again comes to the rescue by defining a static member object for counting constructor calls, as in:

 static int _Init_cnt;

So there's at least one way to ensure that cin and friends have such an extraordinarily useflifetime. The trick is clever enough, but you might still wonder why the draft C++ Standard spells out so much of the machinery. Why not leave it to each implementation to solve the problem in its own way, under the hood as it were.?

The fix is to explicitly initialize an ios::lnit object within f, as in:

void f()
   {      // read during static construction
   ios::Init not_otherwise_used;
   <can now reference cin, etc>
   }

win
wout
werr
wlog

It takes some magic to make these objects wide oriented, but otherwise they are constructed much like their predecessors. The magic represents a major diversion, while the rest is just tedious repetition. So I continue to avoid the complications of showing these recent additions.

• Extract from cin to read from the standard input stream.
• Insert to cout to write to the standard output stream.
• Insert to cerr to write to the standard error stream,
• Insert to clog to write to the standard error stream.

These objects are constructed before any constructor is called to initialize a static object. On rare occasions, as described above, you may need to be sure that cin and friends are initialized even earlier. In that case, be sure that program execution declares an object of class ios::lnit before the first expression that references any of these objects.

You can redirect any of these streams by suppling a replacement pointer to streambuf. For example, you can alter cin to extract from the named file "input" by writing:

#include <fstream>
#include <iostream>
   .....
   filebuf fb;
   fb.open("input", ios::in);
   cin.rdbuf(&fb);