m.htm

有基本了解的程序员或程序爱好者而做

</PRE><A NAME="73175"> </A>
<PRE>...
</PRE><A NAME="73176"> </A>
<PRE>if (r1 == r2) ...
</PRE>
</UL>

<A NAME="73177"> </A>
<P><A NAME="dingp69"></A>
Within the call to <CODE>operator==</CODE>, <CODE>r1</CODE> appears on the left-hand side of the "<CODE>==</CODE>" and is bound to <CODE>lhs</CODE>, while <CODE>r2</CODE> appears on the right-hand side of the "<CODE>==</CODE>" and is bound to <CODE>rhs</CODE>.<SCRIPT>create_link(69);</SCRIPT>

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

<P><A NAME="dingp70"></A><A NAME="72151"></A>
Other abbreviations I employ include <I>ctor</I> for "constructor," <I>dtor</I> for "destructor," and <I>RTTI</I> for C++'s support for runtime type identification (of which <CODE>dynamic_cast</CODE> is the most commonly used <NOBR>component).<SCRIPT>create_link(70);</SCRIPT>

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

<P><A NAME="dingp71"></A><A NAME="74776"></A>
When you allocate memory and fail to free it, you have a memory leak. Memory leaks arise in both C and C++, but in C++, memory leaks leak more than just memory. That's because C++ automatically calls constructors when objects are created, and constructors may themselves allocate resources. For example, consider this <NOBR>code:<SCRIPT>create_link(71);</SCRIPT>

</NOBR></P>

<UL><A NAME="73494"> </A>
<PRE>class Widget { ... };                     // some class &#151; it doesn't
                                          // matter what it is
</PRE><A NAME="73495"> </A>
<PRE>Widget *pw = new Widget;                  // dynamically allocate a
                                          // Widget object
</PRE><A NAME="73496"> </A>
<PRE>...                                       // assume pw is never
                                          // deleted
</PRE>
</UL>

<A NAME="73497"> </A>
<P><A NAME="dingp72"></A>
This code leaks memory, because the <CODE>Widget</CODE> pointed to by <CODE>pw</CODE> is never deleted. However, if the <CODE>Widget</CODE> constructor allocates additional re<A NAME="p7"></A>sources that are to be released when the <CODE>Widget</CODE> is destroyed (such as file descriptors, semaphores, window handles, database locks, etc.), those resources are lost just as surely as the memory is. To emphasize that memory leaks in C++ often leak other resources, too, I usually speak of <I>resource leaks</I> in this book rather than memory <NOBR>leaks.<SCRIPT>create_link(72);</SCRIPT>

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

<P><A NAME="dingp73"></A>
You won't see many inline functions in this book. That's not because I dislike inlining. Far from it, I believe that inline functions are an important feature of C++. However, the criteria for determining whether a function should be inlined can be complex, subtle, and platform-dependent (see <a href="../EC/E_FR.HTM#6729" TARGET="_top" onMouseOver = "self.status = 'Link to EC++ Item 33'; return true" onMouseOut = "self.status = self.defaultStatus">Item E33</A>). As a result, I avoid inlining unless there is a point about inlining I wish to make. When you see a non-inline function in <I>More Effective C++</I>, that doesn't mean I think it would be a bad idea to declare the function <CODE>inline</CODE>, it just means the decision to inline that function is independent of the material I'm examining at that point in the <NOBR>book.<SCRIPT>create_link(73);</SCRIPT>

</NOBR></P><A NAME="73442"> </A>
<A NAME="74000"></A>
<P><A NAME="dingp74"></A>
A few C++ features have been <I>deprecated</I> by the <NOBR><FONT COLOR="#FF0000" SIZE="-2"><B>&deg;</B></FONT><A HREF="http://www.awl.com/cseng/cgi-bin/cdquery.pl?name=committee" onMouseOver="self.status='ISO/ANSI Standardization Committee Home Page'; return true" onMouseOut="self.status=self.defaultStatus" target="_top">standardization</NOBR> committee</A>. Such features are slated for eventual removal from the language, because newer features have been added that do what the deprecated features do, but do it better. In this book, I identify deprecated constructs and explain what features replace them. You should try to avoid deprecated features where you can, but there's no reason to be overly concerned about their use. In the interest of preserving backward compatibility for their customers, compiler vendors are likely to support deprecated features for many <NOBR>years.<SCRIPT>create_link(74);</SCRIPT>

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

<P><A NAME="dingp75"></A>
A <I>client</I> is somebody (a programmer) or something (a class or function, typically) that uses the code you write. For example, if you write a <CODE>Date</CODE> class (for representing birthdays, deadlines, when the Second Coming occurs, etc.), anybody using that class is your client. Furthermore, any sections of code that use the <CODE>Date</CODE> class are your clients as well. Clients are important. In fact, clients are the name of the game! If nobody uses the software you write, why write it? You will find I worry a lot about making things easier for clients, often at the expense of making things more difficult for you, because good software is "clientcentric" &#151; it revolves around clients. If this strikes you as unreasonably philanthropic, view it instead through a lens of self-interest. Do you ever use the classes or functions you write? If so, you're your own client, so making things easier for clients in general also makes them easier for <NOBR>you.<SCRIPT>create_link(75);</SCRIPT>

</NOBR></P><A NAME="11370"> </A>
<A NAME="74758"></A>
<P><A NAME="dingp76"></A>
When discussing class or function templates and the classes or functions generated from them, I reserve the right to be sloppy about the difference between the templates and their instantiations. For example, if <CODE>Array</CODE> is a class template taking a type parameter <CODE>T</CODE>, I may refer to a particular instantiation of the template as an <CODE>Array</CODE>, even though <A NAME="p8"></A><CODE>Array&lt;T&gt;</CODE> is really the name of the class. Similarly, if <CODE>swap</CODE> is a function template taking a type parameter <CODE>T</CODE>, I may refer to an instantiation as <CODE>swap</CODE> instead of <CODE>swap&lt;T&gt;</CODE>. In cases where this kind of shorthand might be unclear, I include template parameters when referring to template <NOBR>instantiations.<SCRIPT>create_link(76);</SCRIPT>

</NOBR></p>

<P><A NAME="dingp77"></A><font ID="mhtitle">Reporting Bugs, Making Suggestions, Getting Book Updates</font><SCRIPT>create_link(77);</SCRIPT>

</P>

<p><A NAME="dingp78"></A><A NAME="74186"> </A>
I have tried to make this book as accurate, readable, and useful as possible, but I know there is room for improvement. If you find an error of any kind &#151; technical, grammatical, typographical, <I>whatever</I> &#151; please tell me about it. I will try to correct the mistake in future printings of the book, and if you are the first person to report it, I will gladly add your name to the book's acknowledgments. If you have other suggestions for improvement, I welcome those, <NOBR>too.<SCRIPT>create_link(78);</SCRIPT>

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

<P><A NAME="dingp79"></A>
I continue to collect guidelines for effective programming in C++. If you have ideas for new guidelines, I'd be delighted if you'd share them with me. Send your guidelines, your comments, your criticisms, and your bug reports to:<SCRIPT>create_link(79);</SCRIPT>

<A NAME="dingp80"></A><Dl><A NAME="74189"> </A><A NAME="74845"></A>
<DD>Scott Meyers
<DD>c/o Editor-in-Chief, Corporate and Professional Publishing
<DD>Addison-Wesley Publishing Company
<DD>1 Jacob Way
<DD>Reading, MA 01867
<DD>U. S. A.<SCRIPT>create_link(80);</SCRIPT>

</DL>
<A NAME="74190"> </A>
<P><A NAME="dingp81"></A>
Alternatively, you may send electronic mail to <A HREF="mailto:[e-mail]"><CODE>[e-mail]</CODE></A>.<SCRIPT>create_link(81);</SCRIPT>

</P><A NAME="74191"> </A>
<P><A NAME="dingp82"></A>
I maintain a list of changes to this book since its first printing, including bug-fixes, clarifications, and technical updates. This list, along with other book-related information, is available from the <NOBR><FONT COLOR="#FF0000" SIZE="-2"><B>&deg;</B></FONT><A HREF="http://www.awl.com/cseng/cgi-bin/cdquery.pl?name=ecmec" onMouseOver="self.status='Addison Wesley Web Site for this product'; return true" onMouseOut="self.status=self.defaultStatus" target="_top">Web</NOBR> site for this book</A>. It is also available via anonymous FTP from <NOBR><FONT COLOR="#FF0000" SIZE="-2"><B>&deg;</B></FONT><A HREF="http://www.awl.com/cseng/cgi-bin/cdquery.pl?name=ecmecftp" onMouseOver="self.status='Addison Wesley Longman Anonymous FTP'; return true" onMouseOut="self.status=self.defaultStatus" target="_top"><CODE>ftp.awl.com</CODE></A></NOBR> in the directory <CODE>cp/mec++</CODE>. If you would like a copy of the list of changes to this book, but you lack access to the Internet, please send a request to one of the addresses above, and I will see that the list is sent to <NOBR>you.<SCRIPT>create_link(82);</SCRIPT>

</NOBR></P><A NAME="73362"> </A>
<P><A NAME="dingp83"></A>
Enough preliminaries. On with the <NOBR>show!<SCRIPT>create_link(83);</SCRIPT>

</NOBR></p>

<!-- SectionName="MEC++ Chapter Intro: Basics" -->

<A NAME="p9"></A><A NAME="10979"></A><DIV ALIGN="CENTER"><FONT SIZE="-1">Back to <A HREF="#p1">Introduction</A> <BR>Continue to <A HREF="#11029">Item 1: Distinguish between pointers and references</A></FONT></DIV>

<P><A NAME="dingp84"></A><font ID="mgtitle">Basics</font><SCRIPT>create_link(84);</SCRIPT>

</P>

<p><A NAME="dingp85"></A><A NAME="72054"></A>
Ah, the basics. Pointers, references, casts, arrays, constructors &#151; you can't get much more basic than that. All but the simplest C++ programs use most of these features, and many programs use them <NOBR>all.<SCRIPT>create_link(85);</SCRIPT>

</NOBR></P>    <P><A NAME="dingp86"></A><A NAME="72055"></A>
In spite of our familiarity with these parts of the language, sometimes they can still surprise us. This is especially true for programmers making the transition from C to C++, because the concepts behind references, dynamic casts, default constructors, and other non-C features are usually a little <NOBR>murky.<SCRIPT>create_link(86);</SCRIPT>

</NOBR></P>    <P><A NAME="dingp87"></A><A NAME="41894"></A>
This chapter describes the differences between pointers and references and offers guidance on when to use each. It introduces the new C++ syntax for casts and explains why the new casts are superior to the C-style casts they replace. It examines the C notion of arrays and the C++ notion of polymorphism, and it describes why mixing the two is an idea whose time will never come. Finally, it considers the pros and cons of default constructors and suggests ways to work around language restrictions that encourage you to have one when none makes <NOBR>sense.<SCRIPT>create_link(87);</SCRIPT>

</NOBR></P>    <P><A NAME="dingp88"></A><A NAME="65857"></A>
By heeding the advice in the items that follow, you'll make progress toward a worthy goal: producing software that expresses your design intentions clearly and <NOBR>correctly.<SCRIPT>create_link(88);</SCRIPT>

</NOBR></p>

<!-- SectionName="M1: Distinguish between pointers and references" -->

<A NAME="11029"></A><DIV ALIGN="CENTER"><FONT SIZE="-1">Back to <A HREF="#10979">Basics</A> <BR>Continue to <A HREF="#77216">Item 2: Prefer C++-style casts</A></FONT></DIV>
<P><A NAME="dingp89"></A><font ID="mititle">Item 1: &nbsp;Distinguish between pointers and references.</font><SCRIPT>create_link(89);</SCRIPT>

</P>

<A NAME="72103"></A>

<A NAME="31049"></A>
<P><A NAME="dingp90"></A>
Pointers and references <i>look</i> different enough (pointers use the "<CODE>*</CODE>" and "<CODE>-&gt;</CODE>" operators, references use "<CODE>.</CODE>"), but they seem to do similar things. Both pointers and references let you refer to other objects indirectly. How, then, do you decide when to use one and not the <NOBR>other?<SCRIPT>create_link(90);</SCRIPT>

</NOBR></P><A NAME="31050"></A>
<P><A NAME="dingp91"></A>
First, recognize that there is no such thing as a null reference. A reference must <I>always</I> refer to some object. As a result, if you have a variable whose purpose is to refer to another object, but it is possible that there might not be an object to refer to, you should make the variable <A NAME="p10"></A>a pointer, because then you can set it to null. On the other hand, if the variable must <I>always</I> refer to an object, i.e., if your design does not allow for the possibility that the variable is null, you should probably make the variable a <NOBR>reference.<SCRIPT>create_link(91);</SCRIPT>

</NOBR></P><A NAME="65886"></A>
<P><A NAME="dingp92"></A>
"But wait," you wonder, "what about underhandedness like <NOBR>this?"<SCRIPT>create_link(92);</SCRIPT>

</NOBR></P><A NAME="65887"></A>
<UL><PRE>char *pc = 0;          // set pointer to null
<A NAME="65888"></A>
char&amp; rc = *pc;        // make reference refer to
                       // dereferenced null pointer</PRE>