📄 00000002.htm
字号:
<BR>虚拟资料让衍生类别能改变基底类别的物件成员所属的类别。严格说来，C++ 并不「 <BR>支援」虚拟资料，但可以模拟出来。不漂亮，但还能用。 <BR> <BR>欲模拟之，基底类别必须有个指标指向成员物件，衍生类别必须提供一个 "new" 到 <BR>的物件，以让原基底类别的指标所指到。该基底类别也要有一个以上正常的建构子， <BR>以提供它们自己的参考（也是透过 "new"），且基底类别的解构子也要 "delete" 掉 <BR>被参考者。 <BR> <BR>举例来说，"Stack" 类别可能有个 Array 成员物件（采用指标），衍生类别 <BR>"StretchableStack" 可能会把基底类别的成员资料 "Array" 覆盖成 <BR>"StretchableArray"。想做到的话，StretchableArray 必须继承自 Array，这样子 <BR>Stack 就会有个 "Array*"。Stack 的正常建构子会用 "new Array" 来初始化它的 <BR>"Array*"，但 Stack 也会有一个（可能是在 "protected:" 里）特别的建构子，以 <BR>自衍生类别中接收一个 "Array*"； StretchableArray 的建构子会用 <BR>"new StretchableArray" 把它传给那个特别的建构子。 <BR> <BR>优点： <BR> * 容易做出 StretchableStack（大部份的程式都继承下来了）。 <BR> * 使用者可把 StretchableStack 当成“是一种”Stack 来传递。 <BR> <BR>缺点： <BR> * 多增加额外的间接存取层，才能碰到 Array。 <BR> * 多增加额外的自由记忆体配置负担（new 与 delete）。 <BR> * 多增加额外的动态系结负担（原因请见下一则 FAQ）。 <BR> <BR>换句话说，在“我们”这一边，很轻松就成功做出 StretchableStack，但所有用户 <BR>却都为此付出代价。不幸的，额外负荷不仅在 StretchableStack 会有，连 Stack <BR>也会。 <BR> <BR>请看下下一则 FAQ，看看使用者会「付出」多少代价。也请读读下一则 FAQ 以後的 <BR>几则（不看其他的，你将得不到平衡的报导）。 <BR> <BR>======================================== <BR> <BR>Q99：虚拟资料和动态资料有何差别？ <BR> <BR>最容易分辨出来的方法，就是看看颇为类似的「虚拟函数」。虚拟成员函数是指：在 <BR>所有子类别中，它的宣告（型态签名）部份必须保持不变，但是定义（本体）的部份 <BR>可以被覆盖（override）。继承下来的成员函数可被覆盖，是子类别的静态性质 <BR>(static property)；它不随任何物件之生命期而动态地改变，同一个子类别的不同 <BR>物件，也不可能会有不同的成员函数的定义。 <BR> <BR>现在请回头重读前面这一段，但稍作些代换： <BR> * 「成员函数」 --> 「成员物件」 <BR> * 「型态签名」 --> 「型别」 <BR> * 「本体」 --> 「真正所属的类别」 <BR>这样子，你就看到虚拟资料的定义。 <BR> <BR>从另一个角度来看，就是把「各个物件」的成员函数与「动态」成员函数区分开来。 <BR>「各个物件」成员函数是指：在任何物件案例中，该成员函数可能会有所不同，可能 <BR>会塞入函数指标来实作出来；这个指标可以是 "const"，因为它在物件生命期中不会 <BR>变更。「动态」成员函数是指：该成员函数会随时间动态地改变；也可能以函数指标 <BR>来做，但该指标不会是 const 的。 <BR> <BR>推而广之，我们得到三种不同的资料成员概念： <BR> * 虚拟资料：成员物件的定义（真正所属的类别）可被子类别覆盖，只要它的宣告 <BR> （型别）维持不变，且此覆盖是子类别的静态性质。 <BR> * 各物件的资料：任何类别的物件在初始化时，可以案例化不同型式（型别）的成 <BR> 员物件（通常是一个 "wrapper" 包起来的物件），且该成员物件真正所属的类别 <BR> ，是把它包起来的那个物件之静态性质。 <BR> * 动态资料：成员物件真正所属的类别，可随时间动态地改变。 <BR> <BR>它们看起来都差不多，是因为 C++ 都不「直接支援」它们，只是「能做得出来」而 <BR>已；在这种情形下，模拟它们的机制也都一样：指向（可能是抽象的）基底类别的指 <BR>标。在直接提供这些 "first class" 抽象化机制的语言中，这三者间的差别十分明 <BR>显，它们各有不同的语法。 <BR> <BR>======================================== <BR> <BR>Q100：我该正常地用指标来配置资料成员，还是该用「成份」(composition)？ <BR> <BR>成份。 <BR> <BR>正常情况下，你的成员资料应该被「包含」在合成的物件里（但也不总是如此； <BR>"wrapper" 物件就是你会想用指标／参考的好例子；N-to-1-uses-a 的关系也需要某 <BR>种指标／参考之类的东西）。 <BR> <BR>有三个理由说明，完全被包含的成员物件（「成份」）的效率，比自由配置物件的指 <BR>标还要好： <BR> <BR> * 额外的间接层，每当你想存取成员物件时。 <BR> * 额外的动态配置（"new" 於建构子中，"delete" 於解构子中）。 <BR> * 额外的动态系结（底下会解释）。 <BR> <BR>======================================== <BR> <BR>Q101：动态配置成员物件有三个效率因素，它们的相对代价是多少？ <BR> <BR>这三个效率因素，上一则 FAQ 有列举出来： <BR> * 以它本身而言，额外的间接层影响不大。 <BR> * 动态配置可能是个效率问题（当有许多配置动作时，典型的 malloc 会拖慢速度 <BR> ；OO 软体会被动态配置拖垮，除非你事先就留意到它了）。 <BR> * 用指标而非物件的话，会带来额外的动态系结。每当 C++ 编译器能知道某物件「 <BR> 真正的」类别，该虚拟函数呼叫就能“静态”地系结住，能够被 inline。Inline <BR> 可能有无限大的 (但你可能只会相信有半打的 :-) 最佳化机会，像是 procedural <BR> integration、暂存器生命期等等事项。三种情形之下，C++ 编译器能知道物件真 <BR> 正的类别：区域变数、整体／静态变数、完全被包含的成员物件。 <BR> <BR>完全被包含的成员物件，可达到很大的最佳化效果，这是「成员物件的指标」所不可 <BR>能办到的。这也就是为什麽采用参考语意的语言，会「与生俱来」就效率不彰的原因 <BR>了。 <BR> <BR>注意：请读读下面三则 FAQs 以得到平衡的观点！ <BR> <BR>======================================== <BR> <BR>Q102："inline virtual" 的成员函数真的会被 "inline" 吗？ <BR> <BR>Yes，可是... <BR> <BR>一个透过指标或参考的 virtual 呼叫总是动态决定的，可能永远都不会被 inline。 <BR>原因：编译器直到执行时（亦即：动态地），才会知道该呼叫哪个程式，因为那一段 <BR>程式，可能会来自呼叫者编译过後才出现的衍生类别。 <BR> <BR>因此，inline virtual 的呼叫可被 inline 的唯一时机是：编译器有办法知道某物 <BR>件「真正所属的类别」之时，这是虚拟函数呼叫里所要知道的事情。这只会发生在： <BR>编译器拥有真正的物件，而非该物件的指标或参考。也就是说：不是区域变数、整体 <BR>／静态物件，就是合成物件里的完全包含物件。 <BR> <BR>注意：inline 和非 inline 的差距，通常会比正常的和虚拟的函数呼叫之差别更为 <BR>显著。譬如，正常的与虚拟的函数呼叫，通常只差两个记忆体参考的动作而已，可是 <BR>inline 与非 inline 函数就会有一个数量级的差距（与数万次影响不大的成员函数 <BR>呼叫相比，函数没有用 inline virtual 的话，会造成 25X 的效率损失！ <BR>[Doug Lea, "Customization in C++," proc Usenix C++ 1990]). <BR> <BR>针对此现象的对策：不要陷入编译器／语言厂商之间，对彼此产品的虚拟函数呼叫， <BR>做永无止尽的性能比较争论（或是广告噱头！）之中。和语言／编译器能否将成员函 <BR>数呼叫做「行内展开」相比，这种比较完全没有意义。也就是说，许多语言编译器厂 <BR>商，拼命强调他们的函数分派方式有多好，但如果他们没做“行内”成员函数呼叫的 <BR>话，整体性能还是会很差，因为 inline－－而非分派－－才是最重要的性能影响因 <BR>素。 <BR> <BR>注意：请读读下两则 FAQs 以看看另一种说法！ <BR> <BR>======================================== <BR> <BR>Q103：看起来我不应该用参考语意了，是吗？ <BR> <BR>错。 <BR> <BR>参考语意是个好东西。我们不能抛弃指标，我们只要不让软体的指标变成一个大老鼠 <BR>窝就行了。在 C++ 里，你可以选择该用参考语意（指标／参考）还是数值语意（物 <BR>件真正包含其他物件）的时机。在大型系统中，两者应该取得平衡。然而如果你全都 <BR>用指标来做的话，速度会大大的降低。 <BR> <BR>接近问题层次的物件，会比较高阶的物件还要大。这些针对「问题空间」抽象化的个 <BR>体本身，通常比它们内部的「数值」更为重要。参考语意应该用於问题空间的物件上 <BR>。 <BR> <BR>注意：问题空间的物件，通常会比解题空间的更为高阶抽象化，所以相对地问题空间 <BR>的物件通常会有较少的交谈性。因此 C++ 给我们一个“理想的”解决法：我们用参 <BR>考语意，来对付那些需要独立的个体识别 (identity) 者，或是大到不适合直接拷贝 <BR>的物件；其他情形则可选择数值语意。因此，使用频率较高的就用数值语意，因为（ <BR>只有）在不造成伤害的场合下，我们才去增加弹性；必要时，我们还是选择效率！ <BR> <BR>还有其他关於实际 OO 设计方面的问题。想精通 OO/C++ 得花时间，以及高素质的训 <BR>练。若你想有个强大的工具，你必须投资下去。 <BR> <BR> <<<< 还不要停下来！ 请一并读读下一则 FAQ！！ >>>> <BR> <BR>======================================== <BR> <BR>Q104：参考语意效率不高，那麽我是否应该用传值呼叫？ <BR> <BR>不。 <BR> <BR>前面的 FAQ 是讨论“成员物件”(member object) 的，而不是函数参数。一般说来 <BR>，位於继承阶层里的物件，应该用参考或指标来传递，而非传值，因为惟有如此你才 <BR>能得到（你想要的）动态系结（传值呼叫和继承不能安全混用，因为如果把大大的子 <BR>类别物件当成基底的物件来传值的话，它会被“切掉”）。 <BR> <BR>除非有足以令人信服的反方理由，否则成员物件应该用数值，而参数该用参考传递。 <BR>前几则 FAQs 提到一些「足以信服的理由」，以支持“成员物件该用参考”一事了。 <BR> <BR>-- <BR>Marshall Cline <BR>-- <BR>Marshall P. Cline, Ph.D. / Paradigm Shift Inc / PO Box 5108 / Potsdam NY 13676 <BR><A HREF="mailto:cline@sun.soe.clarkson.edu">cline@sun.soe.clarkson.edu</A> / 315-353-6100 / FAX: 315-353-6110 <BR> <BR> <BR><CENTER><H1>BBS水木清华站∶精华区</H1></CENTER></BODY></HTML>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -