ITPub博客

首页 > 应用开发 > IT综合 > C++语言常见问题解答(3) (转)

C++语言常见问题解答(3) (转)

原创 IT综合 作者:worldblog 时间:2007-12-10 10:55:04 0 删除 编辑
C++语言常见问题解答(3) (转)[@more@]== Part 3/4  ============================ ============================= 
■□ 第14节:程式风格指导 
============================= 
 
Q81:有任何好的 C++ 程式写作的标准吗? 
 
感谢您阅读这份文件,而不是再发明自己的一套。 
 
但是请不要在 comp.lang.c++ 里问这问题。几乎所有软体工程师,或多或少都把这 
种东西看成是「大玩具」。而且,一些想成为 C++ 程式撰写标准的东西,是由那些 
不熟悉这语言及方法论的人弄出来的,所以最後它只能成为「过去式」的标准。这种 
「摆错位置」的现象,让大家对程式写作标准产生不信任感。 
 
很明显的,在 comp.lang.c++ 问这问题的人,是想使自己更精进,不会因自己的无 
知而绊倒,然而一些回答却只是让情况更糟而已。 
 
======================================== 
 
Q82:程式撰写标准是必要的吗?有它就够了吗? 
 
程式撰写标准不会让不懂 OO 的人变懂;只有训练及经验才有可能。如果它有用处的 
话,那就是抑制住那些琐碎无关紧要的程式片段--当大机构想把零散的程式设计组 
织整合起来时,这些片段常常会出现。 
 
但事实上你要的不光是这种标准而已。它们提供的架构让新手少去担心一些自由度, 
但是系统化的方法论会比这些好看的标准做得更好。组织机构需要的是一致性的设计 
与实行“哲学”,譬如:强型别或弱型别?用指标还是参考介面? stream I/O 还是 
stdio? C++ 程式该不该呼叫 C 的?反过来呢? ABC 该怎麽用?继承该用为实作的 
技巧还是特异化的技巧?该用哪一种测试策略?一一去检查吗?该不该为每个资料成 
员都提供一致的 "get" 和 "set" 介面?介面该由外往内还是由内往外设计?错误状 
况该用 try/catch/throw 还是传回值来处理?……等等。 
 
我们需要的是详细的“设计”部份的「半标准」。我推荐一个三段式标准:训练、谘 
询顾问以及程式库。训练乃提供「密集教学」,谘询顾问让 OO 观念深刻化,而非仅 
仅是被教过而已,高品质的程式库则是提供「长程的教学」。上述三种培训都有很热 
门的市场景况。(【译注】无疑的,这是指美、加地区。)接受过上述培训的组织都 
有如此的忠告:「买现成的吧,不要自己硬干 (Buy, Don't Build.)。」买程式库, 
买训练课程,买开发工具,买谘询顾问。想靠自学来达到成功的工具厂商及应用/系 
统厂商,都会发现成功很困难。 
 
【译注】这一段十分具有参考价值。不过有些背景资料得提供给各位参考。别忘了: 
        作者是美国人,是以该地为背景,且留意一下他所服务的公司是做什麽的.. 
        ... :-)   唉!国内有这麽多的专业顾问公司吗? :-< 
 
少数人会说:程式撰写标准只是「理想」而已,但在上述的组织机构中,它仍有其必 
要性。 
 
底下的 FAQs 提供一些基本的指导惯例及风格。 
 
======================================== 
 
Q83:我们的组织该以以往 C 的经验来决定程式撰写标准吗? 
 
No! 
 
不论你的 C 经验有多丰富,不论你有多高深的 C 能力,好的 C 程式员并不会让你 
直接就成为好的 C++ 程式员。从 C 移到 C++ 并不仅是学习 "++" 的语法语意而已 
,一个组织想达到 oop 的境界,却未将 "OO" 的精神放进 OOP 里的话,只是自欺罢 
了;会计的资产负债表会把他们的愚蠢显现出来。 
 
C++ 程式撰写标准应该由 C++ 专家来调整,不妨先在 comp.lang.c++ 里头问问题( 
但是不要用 "coding standard" 这种字眼;只要这样子问:「这种技巧有何优缺点 
?」)。找个能帮你避开陷阱的高手,上个训练课程,买程式库,看看「好的」程式 
库是否合乎你的程式撰写标准。绝对不要光靠自己来制定标准,除非你对它已有某种 
程度的掌握。没有标准总比有烂标准好,因为不恰当的「官方说法」会让不够聪明的 
平民难以追随。现在 C++ 训练课程及程式库,已有十分兴盛的市场。 
 
再提一件事:当某个东西炙手可热时,招摇撞骗者亦随之而生;务必三思而後行。也 
要问一下从某处修过课的人,因为老手不见得也是个好教员。最後,选个懂得指导别 
人的从业人员,而不是个对此语言/方法论只有过时知识的全职教师。 
 
【译注】善哉斯言! 
 
======================================== 
 
Q84:我该在函数中间或是开头来宣告区域变数? 
 
在第一次用到它的地方附近。 
 
物件在宣告的时候就会被初始化(被建构)。如果在初始化物件的地方没有足够的资 
讯,直到函数中间才有的话,你可以在开头处初始个「空值」给它,等以後再「设定 
」其值;你也可以在函数中间再初始个正确的东西给它。以执行效率来说,一开始就 
让它有正确的值,会比先建立它,搞一搞它,之後再重建它来得好。以像 "String" 
这种简单的例子来看,会有 350% 的速度差距。在你的系统上可能会不同;当然整个 
系统可能不会降低到 300+%,但是“一定”会有不必要的性能衰退现象。 
 
常见的反驳是:「我们会替物件的每个资料提供 "set" 运作行为,则建构时的额外 
耗费就会分散开来。」这比效能负荷更糟,因为你添加了维护的梦靥。替每个资料提 
供 "set" 运作行为就等於对资料不设防:你把内部实作技巧都显露出来了。你隐藏 
到的只有成员物件的实体“名字”而已,但你用到的 List、String 和 float(举例 
来说)型态都曝光了。通常维护会比 cpu 执行时间耗费的资源更多。 
 
区域变数应该在靠近它第一次用到之处宣告。很抱歉,这和 C 老手的习惯不同,但 
是「新的」不见得就是「不好的」。 
 
======================================== 
 
Q85:哪一种原始档命名惯例最好? "foo.C"? "foo.cc"? "foo.cpp"? 
 
如果你已有个惯例,就用它吧。如果没有,看看你的编译器,看它用的是哪一种。典 
型的答案是:".C", ".cc", ".cpp", 或 ".cxx"(很自然的,".C" 副档名是假设该 
档案系统会区分出 ".C" ".c" 大小写)。 
 
在 Paradigm Shift 公司,我们在 Makefiles 里用 ".C",即使是在不区分大小写的 
档案系统下(在有区分的系统中,我们用一个编译器选项:「假设 .c 档案都是 C++ 
的程式」;譬如:IBM CSet++ 用 "-Tdp",Zortech C++ 用 "-cpp",Borland C++用 
"-P",等等)。 
 
======================================== 
 
Q86:哪一种标头档命名惯例最好? "foo.H"? "foo.hh"? "foo.hpp"? 
 
如果你已有个惯例,就用它吧。如果没有,而且你的编辑器不必去区分 C 和 C++ 档 
案的话,只要用 ".h" 就行了,否则就用编辑器所要的,像 ".H"、".hh" 或是 
".hpp"。 
 
在 Paradigm Shift 公司,我们用 ".h" 做为 C 和 C++ 的原始档案(然後,我们就 
不再建那些纯粹的 C 标头档案)。 
 
======================================== 
 
Q87:C++ 有没有像 lint 那样的指导原则? 
 
Yes,有一些常见的例子是危险的。 
但是它们都不尽然是「坏的」,因为有些情况下,再差的例子也得用上去。 
 * "Fred" 类别的设定运算子应该传回 "*this",当成是 "Fred&"(以允许成串的设 
   定指令)。 
 * 有任何虚拟函数的类别,都该有个虚拟解构子。 
 * 若一个类别有 {解构子,设定运算子,拷贝建构子} 其一的话,通常三者也都全 
   部需要。 
 * "Fred" 类别的拷贝建构子和设定运算子,都该将它们的参数加上 "const":分别 
   是 "Fred::Fred(const Fred&)" 和 "Fred& Fred::operator=(const Fred&)" 。 
 * 类别的子物件一定要用初始化串列 (initialization lists) 而不要用设定的方 
   式,因为对使用者自订类别而言,会有很大的效率差距(3x!)。 
 * 许多设定运算子都应该先测试:「我们」是不是「他们」;譬如: 
        Fred& Fred::operator= (const Fred& fred) 
        { 
          if (this == &fred) return *this; 
          //...normal assignment duties... 
          return *this; 
        } 
   有时候没必要测试,但一般说来,这些情况都是:没有必要由使用者提供外显的 
   设定运算子的时候(相对於编译器提供的设定运算子)。 
 * 在那些同时定义了 "+="、"+" 及 "=" 的类别中,"a+=b" 和 "a=a+b" 通常应该 
   做同样的事;其他类似的内建运算子亦同(譬如:a+=1 和 ++a; p[i] 和 *(p+i); 
   等等)。这可使用二元运算子 "op=" 之型式来强制做到;譬如: 
        Fred operator+ (const Fred& a, const Fred& b) 
        { 
          Fred ans = a; 
          ans += b; 
          return ans; 
        } 
   这样一来,有「建构性」的二元运算甚至可以不是夥伴。但常用的运算子有时可 
   能会更有效率地实作出来(譬如,如果 "Fred" 类别本来就是个 "String",且 
   "+=" 必须重新配置/拷贝字串记忆体的话,一开始就知道它的最後长度,可能会 
   比较好)。 
 
 
============================================== 
■□ 第15节:Smalltalk 程式者学习 C++ 之钥 
============================================== 
 
Q88:为什麽 C++ 的 FAQ 有一节讨论 Smalltalk?这是用来攻击 Smalltalk 的吗? 
 
世界上「主要的」两个 OOPLs 是 C++ 与 Smalltalk。由於这个流行的 OOPL 已有第 
二大的使用者总数量,许多新的 C++ 程式者是由 Smalltalk 背景跳过来的。这一节 
会回答以下问题: 
 * 这两个语言的差别? 
 * 从 Smalltalk 跳到 C++ 的程式者,要知道些什麽,才能精通 C++? 
 
这一节 *!*不会*!* 回答这些问题: 
 * 哪一种语言「最好」? 
 * 为什麽 Smalltalk「很烂」? 
 * 为什麽 C++「很烂」? 
 
这可不是对 Smalltalk 恐怖份子挑□,让他们趁我熟睡时戳我的轮胎(在我很难得 
有空休息的这段时间内 :-) 。 
 
======================================== 
 
Q89:C++ 和 Smalltalk 的差别在哪? 
 
最重要的不同是: 
 
 * 静态型别或动态型别? 
 * 继承只能用於产生子型别上? 
 * 数值语意还是参考语意 (value vs reference semantics)? 
 
头两个差异会在这一节中解释,第三点则是下一节的讨论主题。 
 
如果你是 Smalltalk 程式者,现在想学 C++,底下三则 FAQs 最好仔细研读。 
 
======================================== 
 
Q90:什麽是「静态型别」?它和 Smalltalk 有多相似/不像? 
 
静态型别(static typing)是说:编译器会“静态地”(於编译时期)检验各运算 
的型态安全性,而不是产生执行时才会去检查的程式码。例如,在静态型别之下,会 
去侦测比对函数引数的型态签名,不正确的配对会被编译器挑出错误来,而非在执行 
时才被挑出。 
 
OO 的程式里,最常见的「型态不符」错误是:欲对某物件启动个成员函数,但该物 
件并未准备好要处理该运算动作。譬如,如果 "Fred" 类别有成员函数 "f()" 但没 
有 "g()",且 "fred" 是 "Fred" 类别的案例,那麽 "fred.f()" 就是合法的, 
"fred.g()" 则是非法的。C++(静态地)在编译期捕捉型别错误,Smalltalk 则(动 
态地)在执行期捕捉。(技术上,C++ 很像 Pascal--“半”静态型别--因为指 
标转型与 union 都能用来破坏型别系统;这提醒了我们:你用指标转型与 union 的 
频率,只能像你用 "goto" 那样。) 
 
======================================== 
 
Q91:「静态型别」与「动态型别」哪一种比较适合 C++? 
 
若你想最有效率使用 C++,请把她当成静态型别语言来用。 
 
C++ 极富弹性,你可以(藉由指标转型、union 或 #define)让她「长得」像 
Smalltalk。但是不要这样做。这提醒了我们:少用 #define。 
 
有些场合,指标转型和 union 是必要的,甚至是很好的做法,但须谨慎为之。指标 
转型等於是叫编译器完全信赖你。错误的指标转型可能会毁坏堆积、在别的物件记忆 
体中乱搞、呼叫不存在的运作行为、造成一般性错误(general failure)。这是很 
糟糕的事。如果你避免用与这些相关的东西,你的 C++ 程式会更安全、更快,因为 
能在编译期就检测的东西,就不必留到执行期再做。 
 
就算你喜欢动态型别,也请避免在 C++ 里使用,或者请考虑换另一个将型态检查延 
迟到执行期才做的语言。C++ 将型态检验 100% 都放在编译时期;她没有任何执行期 
型态检验的内建机制。如果你把 C++ 当成一个动态型别的 OOPL 来用,你的命运将 
操之汝手。 
 
======================================== 
 
Q92:怎样分辨某个 C++ 物件程式库是否属於动态型别的? 
 
提示 #1:当所有东西都衍生自单一的根类别(root class),通常叫做 "object"。 
提示 #2:当容器类别 container classes,像 List、Stack、Set 等,都不是 
         template 版的。 
提示 #3:当容器类别(List、Stack、Set 等)把插入/取出的元素,都视为指向 
         "Object" 的指标时。(你可以把 Apple 放进容器中,但当你取出时,编 
         译器只知道它是衍生自 Object,所以你得用指标转型将它转回 Apple* ; 
         你最好祈祷它真的是个 Apple,否则你会脑充血的。) 
 
你可用 "dynamic_cast"(於 1994 年才加入的)来使指标转型「安全些」,但这种 
动态测试依旧是“动态”的。这种程式风格是 C++ 动态型别的基本要素,你可以呼 
叫函数:「把这个 Object 转换成 Apple,或是给我个 NULL,如果它不是 Apple的 
话」,你就得到动态型别了:直到执行时期才知道会发生什麽事。 
 
若你用 template 去实作出容器类别,C++ 编译器会静态侦测出 99% 的型态资讯( 
"99%" 并不是真的;有些人宣称能做到 100%,而那些需要持续性 (persistence) 的 
人,只能得到低於 100% 的静态型别检验)。重点是:C++ 透过 template 来做到泛 
型(genericity),而非透过继承。 
 
======================================== 
 
Q93:在 C++ 里怎样用继承?它和 Smalltalk 有何不同? 
 
有些人认为继承是用来重用程式码的。在 C++ 中,这是不对的。说明白点,「继承 
不是『为』重用程式码而设计的。」 
 
【译注】这一个分野相当重要。否则,C++ 使用者就会感染「继承发烧症」 
        (inheritance fever)。 
 
C++ 继承的目的是用来表现介面一致性(产生子类别),而不是重用程式码。C++ 中 
,重用程式码通常是靠「成份」(composition) 而非继承。换句话说,继承主要是用 
来当作「特异化」(specialization) 的技术,而非实作上的技巧。 
 
这是与 Smalltalk 主要的不同之处,在 Smalltalk 里只有一种继承的型式(C++ 有 
"private" 继承--「共享程式码,但不承袭其介面」,有 "public" 继承--表现 
"kind-of" 关系)。Smalltalk 语言非常(相对於只是程式的习惯)允许你置放一个 
override 覆盖(它会去呼叫个「我看不懂」的运作行为),以达到「隐藏住」继承 
下来的运作行为的“效果”。更进一步,Smalltalk 可让观念界的 "is-a" 关系“独 
立於”子类别阶层之外(子型别不必也是子类别;譬如,你可以让某个东西是一个 
Stack,却不必继承自 Stack 类别)。 
 
相反的,C++ 对继承的限制更严:没办法不用到继承就做出“观念上的 is-a”关系 
(有个 C++ 的解决方法:透过 ABC 来分离介面与实作)。C++ 编译器利用公共继承 
额外附的语意资讯,以提供静态型别。 
 
======================================== 
 
Q94:Smalltalk/C++ 不同的继承,在现实里导致的结果是什麽? 
 
Smalltalk 让你做出不是子类别的子型别,做出不是子型别的子类别,它可让 
Smalltalk 程式者不必操心该把哪种资料(位元、表现型式、资料结构)放进类别里 
面(譬如,你可能会把连结串列放到堆叠类别里)。毕竟,如果有人想要个以阵列做 
出的堆叠,他不必真的从堆叠继承过来;喜欢的话,他可以从阵列类别 Array 中继 
承过来,即使 ArrayBasedStack 并“不是”一种阵列!) 
 
在 C++ 中,你不可能不为此操心。只有机制(运作行为的程式码),而非表现法( 
资料位元)可在子类别中被覆盖掉,所以,通常你“不要”把资料结构放进类别里比 
较好。这会促成 Abstract Base Classes (ABCs) 的强烈使用需求。 
 
我喜欢用 ATV 和 Maseratti 之间的差别来比喻。ATV(all terrain vehicle,越野 
车)很好玩,因为你可以「到处逛」,任意开到田野、小溪、人行道等地。另一方面 
,Maseratti 让你能高速行驶,但你只能在公路上面开。就算你喜欢「自由表现力」 
,偏偏喜欢驶向丛林,但也请不要在 C++ 里这麽做;它不适合。 
 
======================================== 
 
Q95:学过「纯种」的 OOPL 之後才能学 C++ 吗? 
 
不是(事实上,这样可能反而会害了你)。 
 
(注意:Smalltalk 是个「纯种」的 OOPL,而 C++ 是个「混血」的 OOPL。)读这 
之前,请先读读前面关於 C++ 与 Smalltalk 差别的 FAQs。 
 
OOPL 的「纯粹性」,并不会让转移到 C++ 更容易些。事实上,典型的动态系结与非 
子型别的继承,会让 Smalltalk 程式者更难学会 C++。Paradigm Shift 公司曾教过 
数千人 OO 技术,我们注意到:有 Smalltalk 背景的人来学 C++,通常和那些根本 
没碰过继承的人学起来差不多累。事实上,对动态型别的 OOPL(通常是,但不全都 
是 Smalltalk)有高度使用经验的人,可能会“更难”学好,因为想把过去的习惯“ 
遗忘”,会比一开始就学习静态型别来得困难。 
 
【译注】作者是以「语言学习」的角度来看的。事实上,若先有 Smalltalk 之类的 
        物件导向观念的背景知识,再来学 C++ 就不必再转换 "paradigm"--物件 
        导向的中心思维是不会变的,变的只是实行细节而已。 
 
======================================== 
 
Q96:什麽是 NIHCL?到哪里拿到它? 
 
NIHCL 代表 "national-institute-of-health's-class-library",美国国家卫生局 
物件程式库。取得法:anonymous FTP 到 [128.231.128.7], 
档案:pub/nihcl-3.0.tar.Z 。 
 
NIHCL(有人念作 "N-I-H-C-L",有人念作 "nickel")是个由 Smalltalk 转移过来 
的 C++ 物件程式库。有些 NIHCL 用到的动态型别很棒(譬如:persistent objects 
,持续性物件),也有些地方动态型别会和 C++ 语言的静态型别相冲突,造成紧张 
关系。 
 
详见前面关於 Smalltalk 的 FAQs。 
 
 
=============================== 
■□ 第16节:参考与数值语意 
=============================== 
 
Q97:什麽是数值以及参考语意?哪一种在 C++ 里最好? 
 
在参考语意 (reference semantics) 中,「设定」是个「指标拷贝」的动作(也就 
是“参考”这个词的本意),数值语意 (value semantics,或 "copy" semantics) 
的设定则是真正地「拷贝其值」,而不是做指标拷贝的动作。C++ 让你选择:用设定 
运算子来拷贝其值(copy/value 语意),或是用指标拷贝方式来拷贝指标 
(reference 语意)。C++ 让你能覆盖掉 (override) 设定运算子,让它去做你想要 
的事,不过系统预设的(而且是最常见的)方式是拷贝其「数值」。 
 
参考语意的优点:弹性、动态系结(在 C++ 里,你只能以传指标或传参考来达到动 
态系结,而不是用传值的方式)。 
 
数值语意的优点:速度。对需要物件(而非指标)的场合来说,「速度」似乎是很奇 
怪的特点,但事实上,我们比较常存取物件本身,较不常去拷贝它。所以偶尔的拷贝 
所付出的代价,(通常)会被拥有「真正的物件本身」、而非仅是指向物件的指标所 
带来的效益弥补过去。 
 
有三个情况,你会得到真正的物件,而不是指向它的指标:区域变数、整体/静态变 
数、完全被某类别包含在内 (fully contained) 的成员物件。这里头最重要的就是 
最後一个(也就是「成份」)。 
 
後面的 FAQs 会有更多关於 copy-vs-reference 语意的资讯,请全部读完,以得到 
较平衡的观点。前几则会刻意偏向数值语意,所以若你只读前面的,你的观点就会有 
所偏颇。 
 
设定 (assignment) 还有别的事项(譬如:shallow vs deep copy)没在这儿提到。 
 
======================================== 
 
Q98:「虚拟资料」是什麽?怎麽样/为什麽该在 C++ 里使用它? 
 
虚拟资料让衍生类别能改变基底类别的物件成员所属的类别。严格说来,C++ 并不「 
支援」虚拟资料,但可以模拟出来。不漂亮,但还能用。 
 
欲模拟之,基底类别必须有个指标指向成员物件,衍生类别必须提供一个 "new" 到 
的物件,以让原基底类别的指标所指到。该基底类别也要有一个以上正常的建构子, 
以提供它们自己的参考(也是透过 "new"),且基底类别的解构子也要 "delete" 掉 
被参考者。 
 
举例来说,"Stack" 类别可能有个 Array 成员物件(采用指标),衍生类别 
"StretchableStack" 可能会把基底类别的成员资料 "Array" 覆盖成 
"StretchableArray"。想做到的话,StretchableArray 必须继承自 Array,这样子 
Stack 就会有个 "Array*"。Stack 的正常建构子会用 "new Array" 来初始化它的 
"Array*",但 Stack 也会有一个(可能是在 "protected:" 里)特别的建构子,以 
自衍生类别中接收一个 "Array*"; StretchableArray 的建构子会用 
"new StretchableArray" 把它传给那个特别的建构子。 
 
优点: 
 * 容易做出 StretchableStack(大部份的程式都继承下来了)。 
 * 使用者可把 StretchableStack 当成“是一种”Stack 来传递。 
 
缺点: 
 * 多增加额外的间接存取层,才能碰到 Array。 
 * 多增加额外的自由记忆体配置负担(new 与 delete)。 
 * 多增加额外的动态系结负担(原因请见下一则 FAQ)。 
 
换句话说,在“我们”这一边,很轻松就成功做出 StretchableStack,但所有用户 
却都为此付出代价。不幸的,额外负荷不仅在 StretchableStack 会有,连 Stack 
也会。 
 
请看下下一则 FAQ,看看使用者会「付出」多少代价。也请读读下一则 FAQ 以後的 
几则(不看其他的,你将得不到平衡的报导)。 
 
======================================== 
 
Q99:虚拟资料和动态资料有何差别? 
 
最容易分辨出来的方法,就是看看颇为类似的「虚拟函数」。虚拟成员函数是指:在 
所有子类别中,它的宣告(型态签名)部份必须保持不变,但是定义(本体)的部份 
可以被覆盖(override)。继承下来的成员函数可被覆盖,是子类别的静态性质 
(static property);它不随任何物件之生命期而动态地改变,同一个子类别的不同 
物件,也不可能会有不同的成员函数的定义。 
 
现在请回头重读前面这一段,但稍作些代换: 
 * 「成员函数」 --> 「成员物件」 
 * 「型态签名」 --> 「型别」 
 * 「本体」     --> 「真正所属的类别」 
这样子,你就看到虚拟资料的定义。 
 
从另一个角度来看,就是把「各个物件」的成员函数与「动态」成员函数区分开来。 
「各个物件」成员函数是指:在任何物件案例中,该成员函数可能会有所不同,可能 
会塞入函数指标来实作出来;这个指标可以是 "const",因为它在物件生命期中不会 
变更。「动态」成员函数是指:该成员函数会随时间动态地改变;也可能以函数指标 
来做,但该指标不会是 const 的。 
 
推而广之,我们得到三种不同的资料成员概念: 
 * 虚拟资料:成员物件的定义(真正所属的类别)可被子类别覆盖,只要它的宣告 
   (型别)维持不变,且此覆盖是子类别的静态性质。 
 * 各物件的资料:任何类别的物件在初始化时,可以案例化不同型式(型别)的成 
   员物件(通常是一个 "wrapper" 包起来的物件),且该成员物件真正所属的类别 
   ,是把它包起来的那个物件之静态性质。 
 * 动态资料:成员物件真正所属的类别,可随时间动态地改变。 
 
它们看起来都差不多,是因为 C++ 都不「直接支援」它们,只是「能做得出来」而 
已;在这种情形下,模拟它们的机制也都一样:指向(可能是抽象的)基底类别的指 
标。在直接提供这些 "first class" 抽象化机制的语言中,这三者间的差别十分明 
显,它们各有不同的语法。 
 
======================================== 
 
Q100:我该正常地用指标来配置资料成员,还是该用「成份」(composition)? 
 
成份。 
 
正常情况下,你的成员资料应该被「包含」在合成的物件里(但也不总是如此; 
"wrapper" 物件就是你会想用指标/参考的好例子;N-to-1-uses-a 的关系也需要某 
种指标/参考之类的东西)。 
 
有三个理由说明,完全被包含的成员物件(「成份」)的效率,比自由配置物件的指 
标还要好: 
 
 * 额外的间接层,每当你想存取成员物件时。 
 * 额外的动态配置("new" 於建构子中,"delete" 於解构子中)。 
 * 额外的动态系结(底下会解释)。 
 
======================================== 
 
Q101:动态配置成员物件有三个效率因素,它们的相对代价是多少? 
 
这三个效率因素,上一则 FAQ 有列举出来: 
 * 以它本身而言,额外的间接层影响不大。 
 * 动态配置可能是个效率问题(当有许多配置动作时,典型的 malloc 会拖慢速度 
   ;OO 软体会被动态配置拖垮,除非你事先就留意到它了)。 
 * 用指标而非物件的话,会带来额外的动态系结。每当 C++ 编译器能知道某物件「 
   真正的」类别,该虚拟函数呼叫就能“静态”地系结住,能够被 inline。Inline 
   可能有无限大的 (但你可能只会相信有半打的 :-) 最佳化机会,像是 procedural 
   integration、暂存器生命期等等事项。三种情形之下,C++ 编译器能知道物件真 
   正的类别:区域变数、整体/静态变数、完全被包含的成员物件。 
 
完全被包含的成员物件,可达到很大的最佳化效果,这是「成员物件的指标」所不可 
能办到的。这也就是为什麽采用参考语意的语言,会「与生俱来」就效率不彰的原因 
了。 
 
注意:请读读下面三则 FAQs 以得到平衡的观点! 
 
======================================== 
 
Q102:"inline virtual" 的成员函数真的会被 "inline" 吗? 
 
Yes,可是... 
 
一个透过指标或参考的 virtual 呼叫总是动态决定的,可能永远都不会被 inline。 
原因:编译器直到执行时(亦即:动态地),才会知道该呼叫哪个程式,因为那一段 
程式,可能会来自呼叫者编译过後才出现的衍生类别。 
 
因此,inline virtual 的呼叫可被 inline 的唯一时机是:编译器有办法知道某物 
件「真正所属的类别」之时,这是虚拟函数呼叫里所要知道的事情。这只会发生在: 
编译器拥有真正的物件,而非该物件的指标或参考。也就是说:不是区域变数、整体 
/静态物件,就是合成物件里的完全包含物件。 
 
注意:inline 和非 inline 的差距,通常会比正常的和虚拟的函数呼叫之差别更为 
显著。譬如,正常的与虚拟的函数呼叫,通常只差两个记忆体参考的动作而已,可是 
inline 与非 inline 函数就会有一个数量级的差距(与数万次影响不大的成员函数 
呼叫相比,函数没有用 inline virtual 的话,会造成 25X 的效率损失! 
[Doug Lea, "Customization in C++," proc Usenix C++ 1990]). 
 
针对此现象的对策:不要陷入编译器/语言厂商之间,对彼此产品的虚拟函数呼叫, 
做永无止尽的性能比较争论(或是广告噱头!)之中。和语言/编译器能否将成员函 
数呼叫做「行内展开」相比,这种比较完全没有意义。也就是说,许多语言编译器厂 
商,拼命强调他们的函数分派方式有多好,但如果他们没做“行内”成员函数呼叫的 
话,整体性能还是会很差,因为 inline--而非分派--才是最重要的性能影响因 
素。 
 
注意:请读读下两则 FAQs 以看看另一种说法! 
 
======================================== 
 
Q103:看起来我不应该用参考语意了,是吗? 
 
错。 
 
参考语意是个好东西。我们不能抛弃指标,我们只要不让软体的指标变成一个大老鼠 
窝就行了。在 C++ 里,你可以选择该用参考语意(指标/参考)还是数值语意(物 
件真正包含其他物件)的时机。在大型系统中,两者应该取得平衡。然而如果你全都 
用指标来做的话,速度会大大的降低。 
 
接近问题层次的物件,会比较高阶的物件还要大。这些针对「问题空间」抽象化的个 
体本身,通常比它们内部的「数值」更为重要。参考语意应该用於问题空间的物件上 
。 
 
注意:问题空间的物件,通常会比解题空间的更为高阶抽象化,所以相对地问题空间 
的物件通常会有较少的交谈性。因此 C++ 给我们一个“理想的”解决法:我们用参 
考语意,来对付那些需要独立的个体识别 (identity) 者,或是大到不适合直接拷贝 
的物件;其他情形则可选择数值语意。因此,使用频率较高的就用数值语意,因为( 
只有)在不造成伤害的场合下,我们才去增加弹性;必要时,我们还是选择效率! 
 
还有其他关於实际 OO 设计方面的问题。想精通 OO/C++ 得花时间,以及高素质的训 
练。若你想有个强大的工具,你必须投资下去。 
 
           <<<< 还不要停下来!  请一并读读下一则 FAQ!! >>>> 
 
======================================== 
 
Q104:参考语意效率不高,那麽我是否应该用传值呼叫? 
 
不。 
 
前面的 FAQ 是讨论“成员物件”(member object) 的,而不是函数参数。一般说来 
,位於继承阶层里的物件,应该用参考或指标来传递,而非传值,因为惟有如此你才 
能得到(你想要的)动态系结(传值呼叫和继承不能安全混用,因为如果把大大的子 
类别物件当成基底的物件来传值的话,它会被“切掉”)。 
 
除非有足以令人信服的反方理由,否则成员物件应该用数值,而参数该用参考传递。 
前几则 FAQs 提到一些「足以信服的理由」,以支持“成员物件该用参考”一事了。 

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/10752043/viewspace-990895/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
  • 博文量
    6241
  • 访问量
    2410606