m.htm

教你如何编写有效简洁的出C＋＋程序

</NOBR></P>

<UL><A NAME="71758"> </A>
<PRE>void f(int);
void f(bool);
</PRE><A NAME="71759"> </A>
<PRE>int x, y;
...
f( x &lt; y );                              // calls f(int), but it
                                         // should call f(bool)
</PRE>
</UL>

<P><A NAME="dingp54"></A><A NAME="71716"> </A>
The enum approximation may thus lead to code whose behavior changes when you submit it to a compiler that truly supports <CODE>bool</CODE>.<SCRIPT>create_link(54);</SCRIPT>

</P><A NAME="71788"> </A>

<P><A NAME="dingp55"></A>
<A NAME="73966"></A><A NAME="73967"></A><A NAME="p4"></A>An alternative is to use a typedef for <CODE>bool</CODE> and constant objects for <CODE>true</CODE> and <CODE>false</CODE>:<SCRIPT>create_link(55);</SCRIPT>

</P>

<UL><A NAME="71795"> </A>
<PRE>typedef int bool;
</PRE><A NAME="71796"> </A>
<PRE>const bool false = 0;
const bool true = 1;
</PRE>
</UL>

<A NAME="71797"> </A>
<P><A NAME="dingp56"></A>
This is compatible with the traditional semantics of C and C++, and the behavior of programs using this approximation won't change when they're ported to <CODE>bool</CODE>-supporting compilers. The drawback is that you can't differentiate between <CODE>bool</CODE> and <CODE>int</CODE> when overloading functions. Both approximations are reasonable. Choose the one that best fits your <NOBR>circumstances.<SCRIPT>create_link(56);</SCRIPT>

</NOBR></P><A NAME="71881"> </A>

<P><A NAME="dingp57"></A>
The second new construct is really four constructs, the casting forms <CODE>static_cast</CODE>, <CODE>const_cast</CODE>, <CODE>dynamic_cast</CODE>, and <CODE>reinterpret_cast</CODE>. If you're not familiar with these casts, you'll want to turn to <A HREF="#77216">Item 2</A> and read all about them. Not only do they do more than the C-style casts they replace, they do it better. I use these new casting forms whenever I need to perform a cast in this <NOBR>book.<SCRIPT>create_link(57);</SCRIPT>

</NOBR></P><A NAME="74524"> </A>

<P><A NAME="dingp58"></A>
There is more to C++ than the language itself. There is also the standard library (see <a href="../EC/E_FR.HTM#8392" TARGET="_top" onMouseOver = "self.status = 'Link to EC++ Item 49'; return true" onMouseOut = "self.status = self.defaultStatus">Item E49</A>). <A NAME="74525"></A>Where possible, I employ the standard <CODE>string</CODE> type instead of using raw <CODE>char*</CODE> pointers, and I encourage you to do the same. <CODE>string</CODE> objects are no more difficult to manipulate than <CODE>char*</CODE>-based strings, and they relieve you of most memory-management concerns. Furthermore, <CODE>string</CODE> objects are less susceptible to memory leaks if an exception is thrown (see Items <A HREF="#5292">9</A> and <a href="#38223">10</A>). A well-implemented <CODE>string</CODE> type can hold its own in an efficiency contest with its <CODE>char*</CODE> equivalent, and it may even do better. (For insight into how this could be, see <A HREF="#6073">Item 29</A>.) If you don't have access to an implementation of the standard <CODE>string</CODE> type, you almost certainly have access to <I>some</I> <CODE>string</CODE>-like class. Use it. Just about anything is preferable to raw <CODE>char*</CODE>s.<SCRIPT>create_link(58);</SCRIPT>

</P><A NAME="72473"> </A>
<A NAME="74732"></A>
<P><A NAME="dingp59"></A>
I use data structures from the standard library whenever I can. Such data structures are drawn from the Standard Template Library (the "STL" &#151; see <A HREF="#5473">Item 35</A>). The STL includes bitsets, vectors, lists, queues, stacks, maps, sets, and more, and you should prefer these standardized data structures to the ad hoc equivalents you might otherwise be tempted to write. Your compilers may not have the STL bundled in, but don't let that keep you from using it. Thanks to Silicon Graphics, you can download a free copy that works with many compilers from the <NOBR><FONT COLOR="#FF0000" SIZE="-2"><B>&deg;</B></FONT><A HREF="http://www.awl.com/cseng/cgi-bin/cdquery.pl?name=stltutorial" onMouseOver="self.status='STL Tutorial and Reference Guide'; return true" onMouseOut="self.status=self.defaultStatus" target="_top">SGI</NOBR> STL web site</A>.<SCRIPT>create_link(59);</SCRIPT>

</P><A NAME="72646"> </A>

<P><A NAME="dingp60"></A>
<A NAME="p5"></A>If you currently use a library of algorithms and data structures and are happy with it, there's no need to switch to the STL just because it's "standard." However, if you have a choice between using an STL component or writing your own code from scratch, you should lean toward using the STL. <A NAME="74750"></A>Remember code reuse? STL (and the rest of the standard library) has lots of code that is very much worth <NOBR>reusing.<SCRIPT>create_link(60);</SCRIPT>

</NOBR></p>
<A NAME="71709"> </A><A NAME="74760"></A>
<P><A NAME="dingp61"></A><font ID="mhtitle">Conventions and Terminology</font><SCRIPT>create_link(61);</SCRIPT>

</P>

<A NAME="72706"></A>
<A NAME="74722"></A>
<P><A NAME="dingp62"></A>
Any time I mention inheritance in this book, I mean public inheritance (see <a href="../EC/E_FR.HTM#6914" TARGET="_top" onMouseOver = "self.status = 'Link to EC++ Item E35'; return true" onMouseOut = "self.status = self.defaultStatus">Item E35</A>). If I don't mean public inheritance, I'll say so explicitly. When drawing inheritance hierarchies, I depict base-derived relationships by drawing arrows from derived classes to base classes. For example, here is a hierarchy from <A HREF="#34883">Item 31</A>:<SCRIPT>create_link(62);</SCRIPT>

</P>
<A NAME="73989"></A><A NAME="73990"></A><A NAME="74752"></A>
<SPAN ID="Image1of1" STYLE="position: absolute; z-index:1; visibility: hidden"><IMG SRC="./IMAGES/GRAPHICS/DIAGRAMS/I_005A1.GIF" BORDER=0></SPAN>
<SPAN ID="Image1of2" STYLE="position: absolute; z-index:1; visibility: hidden"><IMG SRC="./IMAGES/GRAPHICS/DIAGRAMS/I_005A2.GIF" BORDER=0></SPAN>
<SPAN ID="Image1of3" STYLE="position: absolute; z-index:1; visibility: hidden"><IMG SRC="./IMAGES/GRAPHICS/DIAGRAMS/I_005A3.GIF" BORDER=0></SPAN>
<SPAN ID="Image1of4" STYLE="position: absolute; z-index:1; visibility: hidden"><IMG SRC="./IMAGES/GRAPHICS/DIAGRAMS/I_005A4.GIF" BORDER=0></SPAN>
<SPAN ID="Image1of5" STYLE="position: absolute; z-index:1; visibility: hidden"><IMG SRC="./IMAGES/GRAPHICS/DIAGRAMS/I_005A5.GIF" BORDER=0></SPAN>

<SPAN ID="Image1of6" STYLE="position: relative; z-index:1; visibility: hidden"><IMG SRC="./IMAGES/GRAPHICS/DIAGRAMS/I_005A5.GIF" BORDER=0></SPAN>

<A NAME="72673"> </A>
<P><A NAME="dingp63"></A>
This notation is the reverse of the convention I employed in the <A NAME="74617"></A>first (but not the second) edition of <I>Effective C++</I>. I'm now convinced that most C++ practitioners draw inheritance arrows from derived to base classes, and I am happy to follow suit. Within such diagrams, abstract classes (e.g., <CODE>GameObject</CODE>) are shaded and concrete classes (e.g., <CODE>SpaceShip</CODE>) are <NOBR>unshaded.<SCRIPT>create_link(63);</SCRIPT>

</NOBR></P><A NAME="72671"> </A>

<P><A NAME="dingp64"></A>
Inheritance gives rise to pointers and references with two different types, a <I>static type</I> and a <I>dynamic type</I>. The static type of a pointer or reference is its <I>declared</I> type. The dynamic type is determined by the type of object it actually <I>refers</I> to. Here are some examples based on the classes <NOBR>above:<SCRIPT>create_link(64);</SCRIPT>

</NOBR></P>

<UL><A NAME="49303"> </A>
<PRE>GameObject *pgo =                         // static type of pgo is
  new SpaceShip;                          // GameObject*, dynamic
                                          // type is SpaceShip*
</PRE><A NAME="49306"> </A>
<PRE>Asteroid *pa = new Asteroid;              // static type of pa is
                                          // Asteroid*. So is its
                                          // dynamic type
</PRE><A NAME="49307"> </A>
<PRE>pgo = pa;                                 // static type of pgo is
                                          // still (and always)
                                          // GameObject*. Its
                                          // dynamic type is now
                                          // Asteroid*
</PRE><A NAME="49316"> </A>
<A NAME="74830"></A><PRE><A NAME="p6"></A>GameObject&amp; rgo = *pa;                    // static type of rgo is
                                          // GameObject, dynamic
                                          // type is Asteroid
</PRE>
</UL>

<A NAME="49323"></A>

<P><A NAME="dingp65"></A>
These examples also demonstrate a naming convention I like. <CODE>pgo</CODE> is a pointer-to-<CODE>GameObject</CODE>; <CODE>pa</CODE> is a pointer-to-<CODE>Asteroid</CODE>; <CODE>rgo</CODE> is a reference-to-<CODE>GameObject</CODE>. I often concoct pointer and reference names in this <NOBR>fashion.<SCRIPT>create_link(65);</SCRIPT>

</NOBR></P><A NAME="63183"></A>

<P><A NAME="dingp66"></A>
Two of my favorite parameter names are <CODE>lhs</CODE> and <CODE>rhs</CODE>, abbreviations for "left-hand side" and "right-hand side," respectively. To understand the rationale behind these names, consider a class for representing rational <NOBR>numbers:<SCRIPT>create_link(66);</SCRIPT>

</NOBR></P>

<UL><A NAME="73147"> </A>
<PRE>class Rational { ... };
</PRE>
</UL>

<A NAME="73148"> </A>
<P><A NAME="dingp67"></A>If I wanted a function to compare pairs of <CODE>Rational</CODE> objects, I'd declare it like <NOBR>this:<SCRIPT>create_link(67);</SCRIPT>

</NOBR></P>

<UL><A NAME="73154"> </A>
<PRE>bool operator==(const Rational&amp; lhs, const Rational&amp; rhs);
</PRE>
</UL>

<A NAME="49216"> </A>
<P><A NAME="dingp68"></A>
That would let me write this kind of <NOBR>code:<SCRIPT>create_link(68);</SCRIPT>

</NOBR></P>

<UL><A NAME="73174"> </A>
<PRE>Rational r1, r2;