ec1.htm

一个非常适合初学者入门的有关c++的文档

<UL><PRE>
  int scores[NUM_TURNS];     // fine
</PRE>
</UL><A NAME="12650"></A>
<UL><PRE>...
</PRE>
</UL><A NAME="12651"></A>
<UL><PRE>};</PRE>
</UL><A NAME="12532"></A>
<P><A NAME="dingp17"></A>
Unless you're dealing with compilers of primarily historical interest (i.e., those written before 1995), you shouldn't have to use the enum hack. Still, it's worth knowing what it looks like, because it's not uncommon to encounter it in code dating back to those early, simpler <NOBR>times.<SCRIPT>create_link(17);</SCRIPT>
</NOBR></P>
<A NAME="1800"></A>
<P><A NAME="dingp18"></A>
Getting back to the preprocessor, another common (mis)use of the <CODE>#define</CODE> directive is using it to implement macros that look like func<A NAME="p16"></A>tions but that don't incur the overhead of a function call. The canonical example is computing the maximum of two <NOBR>values:<SCRIPT>create_link(18);</SCRIPT>
</NOBR></P>
<A NAME="1801"></A>
<UL><PRE>#define max(a,b) ((a) &gt; (b) ? (a) : (b))
</PRE>
</UL><A NAME="1802"></A>
<P><A NAME="dingp19"></A>
This little number has so many drawbacks, just thinking about them is painful. You're better off playing in the freeway during rush <NOBR>hour.<SCRIPT>create_link(19);</SCRIPT>
</NOBR></P>
<A NAME="1803"></A>
<P><A NAME="dingp20"></A>
Whenever you write a macro like this, you have to remember to parenthesize all the arguments when you write the macro body; otherwise you can run into trouble when somebody calls the macro with an expression. But even if you get that right, look at the weird things that can <NOBR>happen:<SCRIPT>create_link(20);</SCRIPT>
</NOBR></P>
<A NAME="1804"></A>
<UL><PRE>int a = 5, b = 0;
</PRE>
</UL><A NAME="31641"></A>
<UL><PRE>
max(++a, b);         // a is incremented twice
max(++a, b+10);      // a is incremented once
</PRE>
</UL><A NAME="31642"></A>
<P><A NAME="dingp21"></A>
Here, what happens to <CODE>a</CODE> inside <CODE>max</CODE> depends on what it is being compared <NOBR>with!<SCRIPT>create_link(21);</SCRIPT>
</NOBR></P>
<A NAME="1681"></A>
<P><A NAME="dingp22"></A>
Fortunately, you don't need to put up with this nonsense. You can get all the efficiency of a macro plus all the predictable behavior and type-safety of a regular function by using an inline function (see <A HREF="./EC5_FR.HTM#6729" TARGET="_top">Item 33</A>):<SCRIPT>create_link(22);</SCRIPT>
</P>
<A NAME="1682"></A>
<UL><PRE>inline int max(int a, int b) { return a &gt; b ? a : b; }
</PRE>
</UL><A NAME="1809"></A>
<P><A NAME="dingp23"></A>
Now this isn't quite the same as the macro above, because this version of <CODE>max</CODE> can only be called with <CODE>int</CODE>s, but a template fixes that problem quite <NOBR>nicely:<SCRIPT>create_link(23);</SCRIPT>
</NOBR></P>
<A NAME="1810"></A>
<UL><PRE>template&lt;class T&gt;
inline const T&amp; max(const T&amp; a, const T&amp; b)
{ return a &gt; b ? a : b; }
</PRE>
</UL><A NAME="1811"></A>
<P><A NAME="dingp24"></A>
This template generates a whole family of functions, each of which takes two objects convertible to the same type and returns a reference to (a constant version of) the greater of the two objects. Because you don't know what the type <CODE>T</CODE> will be, you pass and return by reference for efficiency (see <A HREF="./EC4_FR.HTM#6133" TARGET="_top">Item 22</A>).<SCRIPT>create_link(24);</SCRIPT>
</P>
<A NAME="12604"></A>
<P><A NAME="dingp25"></A>
By the way, before you consider writing templates for commonly useful functions like <CODE>max</CODE>, check the standard library (see <A HREF="./EC7_FR.HTM#8392" TARGET="_top">Item 49</A>) to see if they already exist. In the case of <CODE>max</CODE>, you'll be pleasantly surprised to find that you can rest on others' laurels: <CODE>max</CODE> is part of the standard C++ <NOBR>library.<SCRIPT>create_link(25);</SCRIPT>
</NOBR></P>
<A NAME="1815"></A>
<P><A NAME="dingp26"></A>
Given the availability of <CODE>const</CODE>s and <CODE>inline</CODE>s, your need for the preprocessor is reduced, but it's not completely eliminated. The day is far from near when you can abandon <CODE>#include</CODE>, and <CODE>#ifdef</CODE>/<CODE>#ifndef</CODE> <A NAME="p17"></A>continue to play important roles in controlling compilation. It's not yet time to retire the preprocessor, but you should definitely plan to start giving it longer and more frequent <NOBR>vacations.<SCRIPT>create_link(26);</SCRIPT>
</NOBR></P>
<!-- SectionName="E2:  Prefer <iostream> to <stdio.h>" -->

<A NAME="95970"></A><A NAME="95971"></A><DIV ALIGN="CENTER"><FONT SIZE="-1">Back to <A HREF="#1790">Item 1: Prefer<CODE>const</CODE> and <CODE>inline</CODE> to <CODE>#define</CODE>.</A><BR>Continue to <A HREF="#1838">Item 3: Prefer <CODE>new</CODE> and <CODE>delete</CODE> to <CODE>malloc</CODE> and <CODE>free</CODE>.</A></FONT></DIV>

<P><A NAME="dingp27"></A><FONT ID="eititle">Item 2: &nbsp;Prefer <CODE>&lt;iostream&gt;</CODE> to <CODE>&lt;stdio.h&gt;</CODE>.</FONT><SCRIPT>create_link(27);</SCRIPT>
</P>

<P><A NAME="dingp28"></A>
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 <CODE>scanf</CODE> and <CODE>printf</CODE> 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 <CODE>printf</CODE>/<CODE>scanf</CODE> 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 <NOBR>farewell.<SCRIPT>create_link(28);</SCRIPT>
</NOBR></P>
<A NAME="1819"></A>
<P><A NAME="dingp29"></A>
Not surprisingly, these weaknesses of <CODE>printf</CODE>/<CODE>scanf</CODE> are the strengths of <CODE>operator&gt;&gt;</CODE> and <CODE>operator&lt;&lt;</CODE>.<SCRIPT>create_link(29);</SCRIPT>
</P>
<A NAME="1820"></A>
<UL><PRE>int i;
Rational r;                           // r is a rational number
</PRE>
</UL><A NAME="12678"></A>
<UL><PRE>...
</PRE>
</UL><A NAME="1821"></A>
<UL><PRE>cin &gt;&gt; i &gt;&gt; r;
cout &lt;&lt; i &lt;&lt; r;
</PRE>
</UL><A NAME="1822"></A>
<P><A NAME="dingp30"></A>
If this code is to compile, there must be functions <CODE>operator&gt;&gt;</CODE> and <CODE>operator&lt;&lt;</CODE> that can work with an object of type <CODE>Rational</CODE> (possibly via implicit type conversion &#151; see <A HREF="../MEC/MC2_FR.HTM#5970" TARGET="_top">Item M5</A>). If these functions are missing, it's an error. (The versions for <CODE>int</CODE>s 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 <CODE>int</CODE> and the second is a <CODE>Rational</CODE>.<SCRIPT>create_link(30);</SCRIPT>
</P>
<A NAME="213141"></A>
<P><A NAME="dingp31"></A>
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 <CODE>scanf</CODE>, 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 <I>not</I> to take an address. Let C++ compilers take care of those details. They have nothing better to do, and you <I>do</I> have better things to do. Finally, note that built-in types like <CODE>int</CODE> are read and written in the same manner as user-defined types like <CODE>Rational</CODE>. Try <I>that</I> using <CODE>scanf</CODE> and <CODE>printf</CODE>!<SCRIPT>create_link(31);</SCRIPT>
</P>
<A NAME="1824"></A>
<P><A NAME="dingp32"></A>
Here's how you might write an output routine for a class representing rational <NOBR>numbers:<SCRIPT>create_link(32);</SCRIPT>
</NOBR></P>
<A NAME="1825"></A><A NAME="p18"></A>
<UL><PRE>class Rational {
public:
  Rational(int numerator = 0, int denominator = 1);
</PRE>
</UL><A NAME="1826"></A>
<UL><PRE>  ...
</PRE>
</UL><A NAME="16827"></A>
<UL><PRE>private:
  int n, d;    // numerator and denominator
</PRE>
</UL><A NAME="1827"></A>
<UL><PRE>friend ostream&amp; operator&lt;&lt;(ostream&amp; s, const Rational&amp; r);
};
</PRE>
</UL><A NAME="12701"></A>
<UL><PRE>ostream&amp; operator&lt;&lt;(ostream&amp; s, const Rational&amp; r)
{
  s &lt;&lt; r.n &lt;&lt; '/' &lt;&lt; r.d;
  return s;
}
</PRE>
</UL><A NAME="1830"></A>

<P><A NAME="dingp33"></A>This version of <CODE>operator&lt;&lt;</CODE> demonstrates some subtle (but important) points that are discussed elsewhere in this book. For example, <CODE>operator&lt;&lt;</CODE> is not a member function (<A HREF="./EC4_FR.HTM#5887" TARGET="_top">Item 19</A> explains why), and the <CODE>Rational</CODE> object to be output is passed into <CODE>operator&lt;&lt;</CODE> as a reference-to-<CODE>const</CODE> rather than as an object (see <A HREF="./EC4_FR.HTM#6133" TARGET="_top">Item 22</A>). The corresponding input function, <CODE>operator&gt;&gt;</CODE>, would be declared and implemented in a similar <NOBR>manner.<SCRIPT>create_link(33);</SCRIPT>
</NOBR></P>

<P><A NAME="dingp34"></A><A NAME="1832"></A>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 &#151; see <A HREF="../MEC/MC4_FR.HTM#40995" TARGET="_top">Item M16</A>) that you have an application in which this makes a significant difference. Bear in mind, though, that this says nothing about iostreams <I>in general</I>, only about particular implementations; see <A HREF="../MEC/MC4_FR.HTM#41253" TARGET="_top">Item M23</A>. Second, the iostream library was modified in some rather fundamental ways during the course of its standardization (see <A HREF="./EC7_FR.HTM#8392" TARGET="_top">Item 49</A>), 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 <CODE>&lt;stdio.h&gt;</CODE> do not, there are rare occasions involving the initialization order of static objects (see <A HREF="./EC7_FR.HTM#8299" TARGET="_top">Item 47</A>) when the standard C library may be more useful simply because you know that you can always call it with <NOBR>impunity.<SCRIPT>create_link(34);</SCRIPT>
</NOBR></P>

<P><A NAME="dingp35"></A><A NAME="3794"></A>
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 <CODE>&lt;stdio.h&gt;</CODE>. After all, even after the transition, you'll still have your <NOBR>memories.<SCRIPT>create_link(35);</SCRIPT>
</NOBR></P>
<A NAME="223413"></A>
<P><A NAME="dingp36"></A>
<A NAME="p19"></A>Incidentally, that's no typo in the Item title; I really
mean <CODE>&lt;iostream&gt;</CODE> and not <CODE>&lt;iostream.h&gt;</CODE>.
Technically speaking, there is no such thing as
<CODE>&lt;iostream.h&gt;</CODE> &#151; the <NOBR><FONT COLOR="#FF0000"
SIZE="-2"><B>&deg;</B></FONT><A