Prefer <iostream> to <stdio.h>

Item 2: Prefer to .
Yes, they're portable. Yes, they're efficient. Yes, you already know how to use them. Yes, yes, yes. But
venerated though they are, the fact of the matter is that scanf and printf and all their ilk could use some
improvement. In particular, they're not type-safe and they're not extensible. Because type safety and extensibility
are cornerstones of the C++ way of life, you might just as well resign yourself to them right now. Besides, the
printf/scanf family of functions separate the variables to be read or written from the formatting information that
controls the reads and writes, just like FORTRAN does. It's time to bid the 1950s a fond farewell.
Not surprisingly, these weaknesses of printf/scanf are the strengths of operator>> and operator<<.
int i;
Rational r;
// r is a rational number
...
cin >> i >> r;
cout << i << r;
If this code is to compile, there must be functions operator>> and operator<< that can work with an object of
type Rational (possibly via implicit type conversion ? see Item M5). If these functions are missing, it's an error.
(The versions for ints are standard.) Furthermore, compilers take care of figuring out which versions of the
operators to call for different variables, so you needn't worry about specifying that the first object to be read or
written is an int and the second is a Rational.
In addition, objects to be read are passed using the same syntactic form as are those to be written, so you don't
have to remember silly rules like you do for scanf, where if you don't already have a pointer, you have to be sure
to take an address, but if you've already got a pointer, you have to be sure not to take an address. Let C++
compilers take care of those details. They have nothing better to do, and you do have better things to do. Finally,
note that built-in types like int are read and written in the same manner as user-defined types like Rational. Try
that using scanf and printf!
Here's how you might write an output routine for a class representing rational numbers:
class Rational {
public:
Rational(int numerator = 0, int denominator = 1);
...
private:
int n, d;
// numerator and denominator
friend ostream& operator<<(ostream& s, const Rational& r);
};
ostream& operator<<(ostream& s, const Rational& r)
{
s << r.n << '/' << r.d;
return s;
}
This version of operator<< demonstrates some subtle (but important) points that are discussed elsewhere in this
book. For example, operator<< is not a member function (Item 19 explains why), and the Rational object to be
output is passed into operator<< as a reference-to-const rather than as an object (see Item 22). The
corresponding input function, operator>>, would be declared and implemented in a similar manner.
Reluctant though I am to admit it, there are some situations in which it may make sense to fall back on the tried
and true. First, some implementations of iostream operations are less efficient than the corresponding C stream
operations, so it's possible (though unlikely ? see Item M16) that you have an application in which this makes a
significant difference. Bear in mind, though, that this says nothing about iostreams in general, only about
particular implementations; see Item M23. Second, the iostream library was modified in some rather
fundamental ways during the course of its standardization (see Item 49), so applications that must be maximally
portable may discover that different vendors support different approximations to the standard. Finally, because
the classes of the iostream library have constructors and the functions in do not, there are rare
occasions involving the initialization order of static objects (see Item 47) when the standard C library may be
more useful simply because you know that you can always call it with impunity.
The type safety and extensibility offered by the classes and functions in the iostream library are more useful than
you might initially imagine, so don't throw them away just because you're used to . After all, even after
the transition, you'll still have your memories.
Incidentally, that's no typo in the Item title; I really mean and not . Technically
speaking, there is no such thing as ? the °standardization committee eliminated it in favor of
when they truncated the names of the other non-C standard header names. The reasons for their doing
this are explained in Item 49, but what you really need to understand is that if (as is likely) your compilers
support both and , the headers are subtly different. In particular, if you #include
, you get the elements of the iostream library ensconced within the namespace std (see Item 28), but if
you #include , you get those same elements at global scope. Getting them at global scope can lead
to name conflicts, precisely the kinds of name conflicts the use of namespaces is designed to preve