📄 ei37.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 37: Never redefine an inherited nonvirtual function</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 LANGUAGE="Javascript">
var dingbase = "EI37_DIR.HTM";
var dingtext = "Item E37, P";
if (self == top) {
top.location.replace(dingbase + this.location.hash);
}
</SCRIPT>
</HEAD>
<BODY BGCOLOR="#FFFFFF" TEXT="#000000" ONLOAD="setResize()">
<!-- SectionName="E37: Never redefine an inherited nonvirtual func" -->
<A NAME="7167"></A>
<DIV ALIGN="CENTER"><FONT SIZE="-1">Back to <A HREF="./EI36_FR.HTM" TARGET="_top">Item 36: Differentiate between inheritance of interface and inheritance of implementation.</A> <BR> Continue to <A HREF="./EI38_FR.HTM" TARGET="_top">Item 38: Never redefine an inherited default parameter value. </A></FONT></DIV>
<P><A NAME="dingp1"></A><FONT ID="eititle">Item 37: Never redefine an inherited nonvirtual function.</FONT><SCRIPT>create_link(1);</SCRIPT>
</P>
<A NAME="7168"></A>
<P><A NAME="dingp2"></A>
There are two ways of looking at this issue: the theoretical way and the pragmatic way. Let's start with the pragmatic way. After all, theoreticians are used to being <NOBR>patient.<SCRIPT>create_link(2);</SCRIPT>
</NOBR></P>
<A NAME="7169"></A>
<P><A NAME="dingp3"></A>
Suppose I tell you that a class <CODE>D</CODE> is publicly derived from a class <CODE>B</CODE> and that there is a public member function <CODE>mf</CODE> defined in class <CODE>B</CODE>. The parameters and return type of <CODE>mf</CODE> are unimportant, so let's just assume they're both <CODE>void</CODE>. In other words, I say <NOBR>this:<SCRIPT>create_link(3);</SCRIPT>
</NOBR></P>
<A NAME="7170"></A>
<UL><PRE>class B {
public:
void mf();
...
};
</PRE>
</UL><A NAME="7173"></A>
<UL><PRE>class D: public B { ... };
</PRE>
</UL><A NAME="7174"></A>
<P><A NAME="dingp4"></A>
Even without knowing anything about <CODE>B</CODE>, <CODE>D</CODE>, or <CODE>mf</CODE>, given an object <CODE>x</CODE> of type <CODE>D</CODE>,<SCRIPT>create_link(4);</SCRIPT>
</P>
<A NAME="7175"></A>
<UL><PRE>
D x; // x is an object of type D
</PRE>
</UL><A NAME="7176"></A><p><A NAME="dingp5"></A>you would probably be quite surprised if <NOBR>this,<SCRIPT>create_link(5);</SCRIPT>
</NOBR></P>
<A NAME="7177"></A>
<UL><PRE>
B *pB = &x; // get pointer to x
</PRE>
</UL><A NAME="7178"></A>
<UL><PRE>
pB->mf(); // call mf through pointer
</PRE>
</UL><A NAME="7179"></A><p><A NAME="dingp6"></A>
behaved differently from <NOBR>this:<SCRIPT>create_link(6);</SCRIPT>
</NOBR></p>
<A NAME="7180"></A>
<UL><PRE>
D *pD = &x; // get pointer to x
</PRE>
</UL><A NAME="7181"></A>
<UL><PRE>
pD->mf(); // call mf through pointer
</PRE>
</UL><A NAME="7182"></A>
<P><A NAME="dingp7"></A>
That's because in both cases you're invoking the member function <CODE>mf</CODE> on the object <CODE>x</CODE>. Because it's the same function and the same object in both cases, it should behave the same way, <NOBR>right?<SCRIPT>create_link(7);</SCRIPT>
</NOBR></P>
<A NAME="7183"></A>
<P><A NAME="dingp8"></A>
Right, it should. But it might not. In particular, it won't if <CODE>mf</CODE> is nonvirtual and <CODE>D</CODE> has defined its own version of <CODE>mf</CODE>:<SCRIPT>create_link(8);</SCRIPT>
</P>
<A NAME="7184"></A>
<UL><PRE>class D: public B {
public:
void mf(); // hides B::mf; see <A HREF="./EI50_FR.HTM#8569" TARGET="_top">Item 50</A>
</PRE>
</UL><A NAME="7188"></A>
<UL><PRE> ...
</PRE>
</UL><A NAME="7189"></A>
<UL><PRE>};
</PRE>
</UL><A NAME="7190"></A>
<UL><PRE><A NAME="p170"></A>
pB->mf(); // calls B::mf
</PRE>
</UL><A NAME="7191"></A>
<UL><PRE>
pD->mf(); // calls D::mf
</PRE>
</UL><A NAME="7192"></A>
<P><A NAME="dingp9"></A>
The reason for this two-faced behavior is that <I>nonvirtual</I> functions like <CODE>B::mf</CODE> and <CODE>D::mf</CODE> are statically bound (see <A HREF="./EI38_FR.HTM#177948" TARGET="_top">Item 38</A>). That means that because <CODE>pB</CODE> is declared to be of type pointer-to-<CODE>B</CODE>, nonvirtual functions invoked through <CODE>pB</CODE> will <I>always</I> be those defined for class <CODE>B</CODE>, even if <CODE>pB</CODE> points to an object of a class derived from <CODE>B</CODE>, as it does in this <NOBR>example.<SCRIPT>create_link(9);</SCRIPT>
</NOBR></P>
<A NAME="19867"></A>
<P><A NAME="dingp10"></A>
<I>Virtual</I> functions, on the other hand, are dynamically bound (again, see <A HREF="./EI38_FR.HTM#177948" TARGET="_top">Item 38</A>), so they don't suffer from this problem. If <CODE>mf</CODE> were a virtual function, a call to <CODE>mf</CODE> through either <CODE>pB</CODE> or <CODE>pD</CODE> would result in an invocation of <CODE>D::mf</CODE>, because what <CODE>pB</CODE> and <CODE>pD</CODE> <I>really</I> point to is an object of type <CODE>D</CODE>.<SCRIPT>create_link(10);</SCRIPT>
</P>
<A NAME="7202"></A>
<P><A NAME="dingp11"></A>
The bottom line, then, is that if you are writing class <CODE>D</CODE> and you redefine a nonvirtual function <CODE>mf</CODE> that you inherit from class <CODE>B</CODE>, <CODE>D</CODE> objects will likely exhibit schizophrenic behavior. In particular, any given <CODE>D</CODE> object may act like either a <CODE>B</CODE> or a <CODE>D</CODE> when <CODE>mf</CODE> is called, and the determining factor will have nothing to do with the object itself, but with the declared type of the pointer that points to it. References exhibit the same baffling behavior as do <NOBR>pointers.<SCRIPT>create_link(11);</SCRIPT>
</NOBR></P>
<A NAME="7203"></A>
<P><A NAME="dingp12"></A>
So much for the pragmatic argument. What you want now, I know, is some kind of theoretical justification for not redefining inherited nonvirtual functions. I am pleased to <NOBR>oblige.<SCRIPT>create_link(12);</SCRIPT>
</NOBR></P>
<A NAME="7210"></A>
<P><A NAME="dingp13"></A>
<A HREF="./EI35_FR.HTM#6914" TARGET="_top">Item 35</A> explains that public inheritance means isa, and <A HREF="./EI36_FR.HTM#7007" TARGET="_top">Item 36</A> describes why declaring a nonvirtual function in a class establishes an invariant over specialization for that class. If you apply these observations to the classes <CODE>B</CODE> and <CODE>D</CODE> and to the nonvirtual member function <CODE>B::mf</CODE>, <NOBR>then<SCRIPT>create_link(13);</SCRIPT>
</NOBR></P>
<UL><A NAME="7211"></A>
<A NAME="dingp14"></A><LI>Everything that is applicable to <CODE>B</CODE> objects is also applicable to <CODE>D</CODE> objects, because every <CODE>D</CODE> object isa <CODE>B</CODE> object;<SCRIPT>create_link(14);</SCRIPT>
<A NAME="7212"></A>
<A NAME="dingp15"></A><LI>Subclasses of <CODE>B</CODE> must inherit both the interface <I>and</I> the implementation of <CODE>mf</CODE>, because <CODE>mf</CODE> is nonvirtual in <CODE>B</CODE>.<SCRIPT>create_link(15);</SCRIPT>
</UL></P>
<A NAME="7214"></A>
<P><A NAME="dingp16"></A>
Now, if <CODE>D</CODE> redefines <CODE>mf</CODE>, there is a contradiction in your design. If <CODE>D</CODE> <EM>really</EM> needs to implement <CODE>mf</CODE> differently from <CODE>B</CODE>, and if every <CODE>B</CODE> object — no matter how specialized — <EM>really</EM> has to use the <CODE>B</CODE> implementation for <CODE>mf</CODE>, then it's simply not true that every <CODE>D</CODE> isa <CODE>B</CODE>. In that case, <CODE>D</CODE> shouldn't publicly inherit from <CODE>B</CODE>. On the other hand, if <CODE>D</CODE> <EM>really</EM> has to publicly inherit from <CODE>B</CODE>, and if <CODE>D</CODE> <EM>really</EM> needs to implement <CODE>mf</CODE> differently from <CODE>B</CODE>, then it's just not true that <CODE>mf</CODE> reflects an invariant over specialization for <CODE>B</CODE>. In that case, <CODE>mf</CODE> should be virtual. Finally, if every <CODE>D</CODE> <EM>really</EM> isa <CODE>B</CODE>, <A NAME="p171"></A>and if <CODE>mf</CODE> really corresponds to an invariant over specialization for <CODE>B</CODE>, then <CODE>D</CODE> can't honestly need to redefine <CODE>mf</CODE>, and it shouldn't try to do <NOBR>so.<SCRIPT>create_link(16);</SCRIPT>
</NOBR></P>
<A NAME="177946"></A>
<P><A NAME="dingp17"></A>
Regardless of which argument applies, something has to give, and under no conditions is it the prohibition on redefining an inherited nonvirtual <NOBR>function.<SCRIPT>create_link(17);</SCRIPT>
</NOBR></P>
<DIV ALIGN="CENTER"><FONT SIZE="-1">Back to <A HREF="./EI36_FR.HTM" TARGET="_top">Item 36: Differentiate between inheritance of interface and inheritance of implementation.</A> <BR> Continue to <A HREF="./EI38_FR.HTM" TARGET="_top">Item 38: Never redefine an inherited default parameter value. </A></FONT></DIV>
</BODY>
</HTML>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -