📄 ei6.htm
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Frameset//EN" "http://www.w3.org/TR/REC-html40/frameset.dtd">
<HTML LANG="EN">
<HEAD>
<title>Effective C++, 2E | Item 6: Use delete on pointer members in destructors</TITLE>
<LINK REL=STYLESHEET HREF=../INTRO/ECMEC.CSS>
<SCRIPT LANGUAGE="Javascript" SRC="../JAVA/COOKIE.JS"></SCRIPT>
<SCRIPT LANGUAGE="Javascript">var imagemax = 0; setCurrentMax(0);</SCRIPT><SCRIPT LANGUAGE="Javascript" SRC="../JAVA/DINGBATS.JS"></SCRIPT>
<SCRIPT>
var dingbase = "EI6_DIR.HTM";
var dingtext = "Item E6, P";
if (self == top) {
top.location.replace(dingbase + this.location.hash);
}
</SCRIPT>
</HEAD>
<BODY BGCOLOR="#FFFFFF" TEXT="#000000" ONLOAD="setResize()">
<!-- SectionName="E6: Use delete on pointer members in destructors." -->
<A NAME="1885"></A>
<DIV ALIGN="CENTER"><FONT SIZE="-1">Back to <A HREF="EI5_FR.HTM" TARGET="_top">Item 5: Use the same form in corresponding uses of new and delete.</A> <BR> Continue to <A HREF="EI7_FR.HTM" TARGET="_top">Item 7: Be prepared for out-of-memory conditions. </A></DIV></FONT>
<P><A NAME="dingp1"></A><FONT ID="eititle">Item 6: Use <CODE>delete</CODE> on pointer members in <NOBR>destructors.</FONT><SCRIPT>create_link(1);</SCRIPT></NOBR>
</P>
<A NAME="1886"></A>
<P><A NAME="dingp2"></A>
Most of the time, classes performing dynamic memory allocation will use <CODE>new</CODE> in the constructor(s) to allocate the memory and will later use <CODE>delete</CODE> in the destructor to free up the memory. This isn't too difficult to get right when you first write the class, provided, of course, that you remember to employ <CODE>delete</CODE> on <I>all</I> the members that could have been assigned memory in <I>any</I> <NOBR>constructor.<SCRIPT>create_link(2);</SCRIPT></NOBR></P>
<A NAME="1887"></A>
<P><A NAME="dingp3"></A>
However, the situation becomes more difficult as classes are maintained and enhanced, because the programmers making the modifications to the class may not be the ones who wrote the class in the first <A NAME="p25"></A>place. Under those conditions, it's easy to forget that adding a pointer member almost always requires each of the <NOBR>following:<SCRIPT>create_link(3);</SCRIPT></NOBR></p>
<UL><A NAME="1888"></A>
<A NAME="dingp4"></A><LI>Initialization of the pointer in each of the constructors. If no memory is to be allocated to the pointer in a particular constructor, the pointer should be initialized to 0 (i.e., the null <NOBR>pointer).<SCRIPT>create_link(4);</SCRIPT></NOBR>
<A NAME="1889"></A>
<A NAME="dingp5"></A><LI>Deletion of the existing memory and assignment of new memory in the assignment operator. (See also <A HREF="./EI17_FR.HTM#2264" TARGET="_top">Item <NOBR>17</A>.)<SCRIPT>create_link(5);</SCRIPT></NOBR>
<A NAME="1890"></A>
<A NAME="dingp6"></A><LI>Deletion of the pointer in the <NOBR>destructor.<SCRIPT>create_link(6);</SCRIPT></NOBR>
</UL>
<P><A NAME="dingp7"></A><A NAME="1891"></A>
If you forget to initialize a pointer in a constructor, or if you forget to handle it inside the assignment operator, the problem usually becomes apparent fairly quickly, so in practice those issues don't tend to plague you. Failing to delete the pointer in the destructor, however, often exhibits no obvious external symptoms. Instead, it manifests itself as a subtle memory leak, a slowly growing cancer that will eventually devour your address space and drive your program to an early demise. Because this particular problem doesn't usually call attention to itself, it's important that you keep it in mind whenever you add a pointer member to a <NOBR>class.<SCRIPT>create_link(7);</SCRIPT></NOBR></P>
<P><A NAME="dingp8"></A><A NAME="1892"></A>
Note, by the way, that deleting a null pointer is always safe (it does nothing). Thus, if you write your constructors, your assignment operators, and your other member functions such that each pointer member of the class is always either pointing to valid memory or is null, you can merrily <CODE>delete</CODE> away in the destructor without regard for whether you ever used <CODE>new</CODE> for the pointer in <NOBR>question.<SCRIPT>create_link(8);</SCRIPT></NOBR></P>
<P><A NAME="dingp9"></A><A NAME="1893"></A>
There's no reason to get fascist about this Item. For example, you certainly don't want to use <CODE>delete</CODE> on a pointer that wasn't initialized via <CODE>new</CODE>, and, except in the case of smart pointer objects (see <A HREF="../MEC/MI28_FR.HTM#61766" TARGET="_top">Item M28</A>), you almost <I>never</I> want to delete a pointer that was passed to you in the first place. In other words, your class destructor usually shouldn't be using <CODE>delete</CODE> unless your class members were the ones who used <CODE>new</CODE> in the first <NOBR>place.<SCRIPT>create_link(9);</SCRIPT></NOBR></P>
<P><A NAME="dingp10"></A><A NAME="223293"></A>
Speaking of smart pointers, one way to avoid the need to delete pointer members is to replace those members with smart pointer objects like the standard C++ Library's <CODE>auto_ptr</CODE>. To see how this can work, take a look at Items <A HREF="../MEC/MI9_FR.HTM#5292" TARGET="_top">M9</A> and <A HREF="../MEC/MI10_FR.HTM#38223" TARGET="_top"><NOBR>M10</A>.<SCRIPT>create_link(10);</SCRIPT></NOBR>
</P>
<DIV ALIGN="CENTER"><FONT SIZE="-1">Back to <A HREF="EI5_FR.HTM" TARGET="_top">Item 5: Use the same form in corresponding uses of new and delete.</A> <BR> Continue to <A HREF="EI7_FR.HTM" TARGET="_top">Item 7: Be prepared for out-of-memory conditions. </A></DIV></FONT>
</BODY>
</HTML>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -