C++语言常见问题解答3.docx
《C++语言常见问题解答3.docx》由会员分享,可在线阅读,更多相关《C++语言常见问题解答3.docx(20页珍藏版)》请在冰点文库上搜索。
C++语言常见问题解答3
C++语言常见问题解答(3)
2007-8-10 作者:
编辑:
眼镜丢了 点击进入论坛
第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;
file:
//...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)。