ec1.htm

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

HREF="http://www.awl.com/cseng/cgi-bin/cdquery.pl?name=committee" onMouseOver
= "self.status = 'Link to the C++ Standardardization Committee'; return true"
onMouseOut = "self.status = self.defaultStatus"
TARGET="_top">standardization</NOBR> committee</A> eliminated it in favor of
<CODE>&lt;iostream&gt;</CODE> when they truncated the names of the other
non-C standard header names. The reasons for their doing this are explained
in <A HREF="./EC7_FR.HTM#8392" TARGET="_top">Item 49</A>, but what you really
need to understand is that if (as is likely) your compilers support both
<CODE>&lt;iostream&gt;</CODE> and <CODE>&lt;iostream.h&gt;</CODE>, the
headers are subtly different. In particular, if you <CODE>#include</CODE>
<CODE>&lt;iostream&gt;</CODE>, you get the elements of the iostream library
ensconced within the namespace <CODE>std</CODE> (see <A
HREF="./EC4_FR.HTM#6429" TARGET="_top">Item 28</A>), but if you
<CODE>#include</CODE> <CODE>&lt;iostream.h&gt;</CODE>, 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 prevent. Besides, <CODE>&lt;iostream&gt;</CODE> is less to type
than <CODE>&lt;iostream.h&gt;</CODE>. For many people, that's reason enough
to prefer <NOBR>it.<SCRIPT>create_link(36);</SCRIPT>
</NOBR></P> <!--SectionName="E3: Prefer new and delete to malloc and free" --> <A NAME="1838"></A><DIV ALIGN="CENTER"><FONT SIZE="-1">Back to <A HREF="#95970">Item 2: Prefer <CODE>&lt;iostream&gt;</CODE> to <CODE>&lt;stdio.h&gt;</CODE></A>.<BR>&nbsp;&nbsp; Continue to <A HREF="#1854">Item 4: Prefer C++-style comments.</A></FONT></DIV>

<P><A NAME="dingp37"></A><FONT ID="eititle">Item 3: &nbsp; Prefer <CODE>new</CODE> and <CODE>delete</CODE> to <CODE>malloc</CODE> and <CODE>free</CODE>.</FONT><SCRIPT>create_link(37);</SCRIPT>
</P>

<A NAME="1839"></A>
<P><A NAME="dingp38"></A>
The problem with <CODE>malloc</CODE> and <CODE>free</CODE> (and their variants) is simple: they don't know about constructors and <NOBR>destructors.<SCRIPT>create_link(38);</SCRIPT>
</NOBR></P>
<A NAME="1840"></A>
<P><A NAME="dingp39"></A>
Consider the following two ways to get space for an array of 10 <CODE>string</CODE> objects, one using <CODE>malloc</CODE>, the other using <CODE>new</CODE>:<SCRIPT>create_link(39);</SCRIPT>
</P>
<A NAME="1842"></A>
<UL><PRE>string *stringArray1 =
  static_cast&lt;string*&gt;(malloc(10 * sizeof(string)));
</PRE>
</UL><A NAME="1843"></A>
<UL><PRE>string *stringArray2 = new string[10];
</PRE>
</UL><A NAME="1844"></A>
<P><A NAME="dingp40"></A>
Here <CODE>stringArray1</CODE> points to enough memory for 10 <CODE>string</CODE> objects, but no objects have been constructed in that memory. Furthermore, without jumping through some rather obscure linguistic hoops (such as those described in Items <A HREF="../MEC/MC1_FR.HTM#5218" TARGET="_top">M4</A> and <A HREF="../MEC/MC2_FR.HTM#33985" TARGET="_top">M8</A>), you have no way to initialize the objects in the array. In other words, <CODE>stringArray1</CODE> is pretty useless. In contrast, <CODE>stringArray2</CODE> points to an array of 10 fully constructed <CODE>string</CODE> objects, each of which can safely be used in any operation taking a <CODE>string</CODE>.<SCRIPT>create_link(40);</SCRIPT>
</P>
<A NAME="1845"></A>
<P><A NAME="dingp41"></A>
Nonetheless, let's suppose you magically managed to initialize the objects in the <CODE>stringArray1</CODE> array. Later on in your program, then, you'd expect to do <NOBR>this:<SCRIPT>create_link(41);</SCRIPT>
</NOBR></P>
<A NAME="1846"></A>
<UL><PRE>free(stringArray1);
</PRE>
</UL><A NAME="1847"></A>
<UL><PRE>
delete [] stringArray2;      // see <A HREF="./EC2_FR.HTM#1869" TARGET="_top">Item 5</A> for why the
                             // "[]" is necessary
</PRE>
</UL><A NAME="1848"></A>
<P><A NAME="dingp42"></A>
The call to <CODE>free</CODE> will release the memory pointed to by <CODE>stringArray1</CODE>, but no destructors will be called on the <CODE>string</CODE> objects in that mem<A NAME="p20"></A>ory. If the <CODE>string</CODE> objects themselves allocated memory, as <CODE>string</CODE> objects are wont to do, all the memory they allocated will be lost. On the other hand, when <CODE>delete</CODE> is called on <CODE>stringArray2</CODE>, a destructor is called for each object in the array before any memory is <NOBR>released.<SCRIPT>create_link(42);</SCRIPT>
</NOBR></P>
<A NAME="1849"></A>
<P><A NAME="dingp43"></A>
Because <CODE>new</CODE> and <CODE>delete</CODE> interact properly with constructors and destructors, they are clearly the superior <NOBR>choice.<SCRIPT>create_link(43);</SCRIPT>
</NOBR></P>
<A NAME="104344"></A>
<P><A NAME="dingp44"></A>
Mixing <CODE>new</CODE> and <CODE>delete</CODE> with <CODE>malloc</CODE> and <CODE>free</CODE> is usually a bad idea. When you try to call <CODE>free</CODE> on a pointer you got from <CODE>new</CODE> or call <CODE>delete</CODE> on a pointer you got from <CODE>malloc</CODE>, the results are undefined, and we all know what "undefined" means: it means it works during development, it works during testing, and it blows up in your most important customers' <NOBR>faces.<SCRIPT>create_link(44);</SCRIPT>
</NOBR></P>
<A NAME="13170"></A>
<P><A NAME="dingp45"></A>
The incompatibility of <CODE>new</CODE>/<CODE>delete</CODE> and <CODE>malloc</CODE>/<CODE>free</CODE> can lead to some interesting complications. For example, the <CODE>strdup</CODE> function commonly found in <CODE>&lt;string.h&gt;</CODE> takes a <CODE>char*</CODE>-based string and returns a copy of <NOBR>it:<SCRIPT>create_link(45);</SCRIPT>
</NOBR></P>
<A NAME="1851"></A>
<UL><PRE>
char * strdup(const char *ps);      // return a copy of what
                                    // ps points to
</PRE>
</UL><A NAME="1852"></A>
<P><A NAME="dingp46"></A>
At some sites, both C and C++ use the same version of <CODE>strdup</CODE>, so the memory allocated inside the function comes from <CODE>malloc</CODE>. As a result, unwitting C++ programmers calling <CODE>strdup</CODE> might overlook the fact that they must use <CODE>free</CODE> on the pointer returned from <CODE>strdup</CODE>. But wait! To forestall such complications, some sites might decide to rewrite <CODE>strdup</CODE> for C++ and have this rewritten version call <CODE>new</CODE> inside the function, thereby mandating that callers later use <CODE>delete</CODE>. As you can imagine, this can lead to some pretty nightmarish portability problems as code is shuttled back and forth between sites with different forms of <CODE>strdup</CODE>.<SCRIPT>create_link(46);</SCRIPT>
</P>
<A NAME="12827"></A>
<P><A NAME="dingp47"></A>
Still, C++ programmers are as interested in code reuse as C programmers, and it's a simple fact that there are lots of C libraries based on <CODE>malloc</CODE> and <CODE>free</CODE> containing code that is very much worth reusing. When taking advantage of such a library, it's likely you'll end up with the responsibility for <CODE>free</CODE>ing memory <CODE>malloc</CODE>ed by the library and/or <CODE>malloc</CODE>ing memory the library itself will <CODE>free</CODE>. That's fine. There's nothing wrong with calling <CODE>malloc</CODE> and <CODE>free</CODE> inside a C++ program as long as you make sure the pointers you get from <CODE>malloc</CODE> always meet their maker in <CODE>free</CODE> and the pointers you get from <CODE>new</CODE> eventually find their way to <CODE>delete</CODE>. The problems start when you get sloppy and try to mix <CODE>new</CODE> with <CODE>free</CODE> or <CODE>malloc</CODE> with <CODE>delete</CODE>. That's just asking for <NOBR>trouble.<SCRIPT>create_link(47);</SCRIPT>
</NOBR></P>
<A NAME="1853"></A>
<P><A NAME="dingp48"></A>
<A NAME="p21"></A>Given that <CODE>malloc</CODE> and <CODE>free</CODE> are ignorant of constructors and destructors and that mixing <CODE>malloc</CODE>/<CODE>free</CODE> with <CODE>new</CODE>/<CODE>delete</CODE> can be more volatile than a fraternity rush party, you're best off sticking to an exclusive diet of <CODE>new</CODE>s and <CODE>delete</CODE>s whenever you <NOBR>can.<SCRIPT>create_link(48);</SCRIPT>
</NOBR></P>

<!-- SectionName="E4: Prefer C++-style comments" -->

<A NAME="1854"></A>

<DIV ALIGN="CENTER"><FONT SIZE="-1">Back to <A HREF="#1838">Item 3: Prefer <CODE>new</CODE> and <CODE>delete</CODE> to <CODE>malloc</CODE> and <CODE>free</CODE>.</A><BR>Continue to <A HREF="./EC2_FR.HTM" TARGET="_top">Memory Management</A></FONT></DIV>

<P><A NAME="dingp49"></A><FONT ID="eititle">Item 4: Prefer C++-style comments.</FONT><SCRIPT>create_link(49);</SCRIPT>
</P>

<A NAME="1855"></A>
<P><A NAME="dingp50"></A>
The good old C comment syntax works in C++ too, but the newfangled C++ comment-to-end-of-line syntax has some distinct advantages. For example, consider this <NOBR>situation:<SCRIPT>create_link(50);</SCRIPT>
</NOBR></P>
<A NAME="1856"></A>
<UL><PRE>if ( a &gt; b ) {
  // int temp = a;    // swap a and b
  // a = b;
  // b = temp;
}
</PRE>
</UL><A NAME="1857"></A>
<P><A NAME="dingp51"></A>
Here you have a code block that has been commented out for some reason or other, but in a stunning display of software engineering, the programmer who originally wrote the code actually included a comment to indicate what was going on. When the C++ comment form was used to comment out the block, the embedded comment was of no concern, but there could have been a serious problem had everybody chosen to use C-style <NOBR>comments:<SCRIPT>create_link(51);</SCRIPT>
</NOBR></P>
<A NAME="1858"></A>
<UL><PRE>if ( a &gt; b ) {
  /*  int temp = a;  /* swap a and b */
      a = b;
      b = temp;
  */
}
</PRE>
</UL><A NAME="1859"></A>
<P><A NAME="dingp52"></A>
Notice how the embedded comment inadvertently puts a premature end to the comment that is supposed to comment out the code <NOBR>block.<SCRIPT>create_link(52);</SCRIPT>
</NOBR></P>
<A NAME="1860"></A>
<P><A NAME="dingp53"></A>
C-style comments still have their place. For example, they're invaluable in header files that are processed by both C and C++ compilers. Still, if you can use C++-style comments, you are often better off doing <NOBR>so.<SCRIPT>create_link(53);</SCRIPT>
</NOBR></P>
<A NAME="1861"></A>
<P><A NAME="dingp54"></A>
It's worth pointing out that retrograde preprocessors that were written only for C don't know how to cope with C++-style comments, so things like the following sometimes don't work as <NOBR>expected:<SCRIPT>create_link(54);</SCRIPT>
</NOBR></P>
<A NAME="1862"></A>
<UL><PRE>#define LIGHT_SPEED   3e8    // m/sec (in a vacuum)
</PRE>
</UL><A NAME="1863"></A>
<P><A NAME="dingp55"></A>
Given a preprocessor unfamiliar with C++, the comment at the end of the line becomes <I>part of the macro! </I>Of course, as is discussed in <A HREF="#1790">Item 1</A>, you shouldn't be using the preprocessor to define constants <NOBR>anyway.<SCRIPT>create_link(55);</SCRIPT>
</NOBR></P>
<DIV ALIGN="CENTER"><FONT SIZE="-1">Back to <A HREF="#1854">Item 4: Prefer C++-style comments</A>
<BR>Continue to <A HREF="./EC2_FR.HTM" TARGET="_top">Chapter 2: Memory Management</A></FONT></DIV>
</BODY>
</HTML>