分享
 
 
 

转贴:C++语言常见问题解:#81 ~ #93

王朝c/c++·作者佚名  2006-01-08
窄屏简体版  字體: |||超大  

这是我从台湾的http://www.cis.nctu.edu.tw/chinese/doc/research/c++/C++FAQ-Chinese/发现的《C++ Frequently Asked Questions》的繁体翻译,作者是:叶秉哲,也是《C++ Programming Language》3/e繁体版的译者,该文章是非常的好,出于学习用途而将它转贴,本人未取得作者的授权,原文章的版权仍然归属原作者.

C++语言常见问题解

== Part 3/4 ============================

comp.lang.c++ Frequently Asked Questions list (with answers, fortunately).

Copyright (C) 1991-96 Marshall P. Cline, Ph.D.

Posting 3 of 4.

Posting #1 explains copying permissions, (no)warranty, table-of-contents, etc

=============================

■□ 第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++ 编译器利用公共继承

额外附的语意信息,以提供静态型别。

========================================

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有