推荐：Ｃ＋＋语言常见问题解答

【中译对照表】　
　
　　　　　　
　　　　　　　　abstraction　　　　　　　　　　　　　抽象化.　
　　　　　　　　access　　　　　　　　　　　　　　　　　　存取.　
　　　　　　　　access　function　　　　　　　　　存取函数.　
　　　　　　　　alias　　　　　　　　　　　　　　　　　　　别名.　
　　　　　　　　argument　　　　　　　　　　　　　　　　引数.　
　　　　　　　　arity　　　　　　　　　　　　　　　　　　　元数.　
　　　　　　　　assignment　　　　　　　　　　　　　　设定.　
　　　　　　　　associativity　　　　　　　　　　　结合律.　
　　　　　　　　base　class　　　　　　　　　　　　　　基底类别.　
　　　　　　　　binding　　　　　　　　　　　　　　　　　系结.　
　　　　　　　　call　　　　　　　　　　　　　　　　　　　　呼叫.　
　　　　　　　　class　　　　　　　　　　　　　　　　　　　类别、物件类别.　
　　　　　　　　composition　　　　　　　　　　　　　成份、零件.　
　　　　　　　　constructor　　　　　　　　　　　　　建构子（建构元）.　
　　　　　　　　container　　　　　　　　　　　　　　　容器.　
　　　　　　　　container　class　　　　　　　　　容器类别.　
　　　　　　　　data　member　　　　　　　　　　　　　资料成员.　
　　　　　　　　declaration　　　　　　　　　　　　　宣告　　　　　　　　　　　　　　　　　　　　　　　　　　　　<名词>.　
　　　　　　　　declare　　　　　　　　　　　　　　　　　宣告　　　　　　　　　　　　　　　　　　　　　　　　　　　　<动词>.　
　　　　　　　　default　　　　　　　　　　　　　　　　　预设、内定.　
　　　　　　　　define　　　　　　　　　　　　　　　　　　定义　　　　　　　　　　　　　　　　　　　　　　　　　　　　<动词>.　
　　　　　　　　definition　　　　　　　　　　　　　　定义　　　　　　　　　　　　　　　　　　　　　　　　　　　　<名词>.　
　　　　　　　　dereference　　　　　　　　　　　　　解参用、解参考.　
　　　　　　　　derive　　　　　　　　　　　　　　　　　　衍生.　
　　　　　　　　destructor　　　　　　　　　　　　　　解构子（解构元）.　
　　　　　　　　dispatch　　　　　　　　　　　　　　　　分派、函数分派.　
　　　　　　　　dynamic　　　　　　　　　　　　　　　　　动态.　
　　　　　　　　encapsulation　　　　　　　　　　　封装、封装性.　
　　　　　　　　exception　　　　　　　　　　　　　　　例外、例外状况（异常）.　
　　　　　　　　exception　handling　　　　　　例外处理.　
　　　　　　　　explicit　　　　　　　　　　　　　　　　明显的、外显的　　　　　　　　　　　　　　　　　　<形容词>.　
　　　　　　　　expression　　　　　　　　　　　　　　运算式.　
　　　　　　　　friend　　　　　　　　　　　　　　　　　　夥伴.　
　　　　　　　　function　　　　　　　　　　　　　　　　函数.　
　　　　　　　　genericity　　　　　　　　　　　　　　泛型.　
　　　　　　　　header　file　　　　　　　　　　　　　标头档（引入档、含括档）.　
　　　　　　　　hide　　　　　　　　　　　　　　　　　　　　遮蔽.　
　　　　　　　　hierarchy　　　　　　　　　　　　　　　阶层.　
　　　　　　　　identity　　　　　　　　　　　　　　　　个体识别.　
　　　　　　　　implement　　　　　　　　　　　　　　　实作　　　　　　　　　　　　　　　　　　　　　　　　　　　　<动词>.　
　　　　　　　　implementation　　　　　　　　　　实作　　　　　　　　　　　　　　　　　　　　　　　　　　　　<名词>.　
　　　　　　　　inherit　　　　　　　　　　　　　　　　　继承　　　　　　　　　　　　　　　　　　　　　　　　　　　　<动词>.　
　　　　　　　　inheritance　　　　　　　　　　　　　继承　　　　　　　　　　　　　　　　　　　　　　　　　　　　<名词>.　
　　　　　　　　inline　　　　　　　　　　　　　　　　　　行内（列内、内嵌）.　
　　　　　　　　inspector　　　　　　　　　　　　　　　查询子.　
　　　　　　　　instance　　　　　　　　　　　　　　　　案例、实体（执行个体）.　
　　　　　　　　instantiate　　　　　　　　　　　　　案例化、实体化　　　　　　　　　　　　　　　　　　<动词>.　
　　　　　　　　instantiation　　　　　　　　　　　案例　　　　　　　　　　　　　　　　　　　　　　　　　　　　<名词>.　
　　　　　　　　keyword　　　　　　　　　　　　　　　　　关键字、保留字.　
　　　　　　　　mangle　　　　　　　　　　　　　　　　　　签名编码　　　　　　　　　　　　　　　　　　　　　　　　<动词>.　
　　　　　　　　mangling　　　　　　　　　　　　　　　　签名编码　　　　　　　　　　　　　　　　　　　　　　　　<名词>.　
　　　　　　　　member　　　　　　　　　　　　　　　　　　成员.　
　　　　　　　　member　function　　　　　　　　　成员函数.　
　　　　　　　　member　object　　　　　　　　　　　成员物件.　
　　　　　　　　method　　　　　　　　　　　　　　　　　　运作方法、运算方法.　
　　　　　　　　module　　　　　　　　　　　　　　　　　　模组.　
　　　　　　　　multiple　inheritance　　　　多重继承.　
　　　　　　　　mutator　　　　　　　　　　　　　　　　　更动子.　
　　　　　　　　object　　　　　　　　　　　　　　　　　　物件（个体）.　
　　　　　　　　OO　　　　　　　　　　　　　　　　　　　　　　物件导向（个体导向）.　
　　　　　　　　OOP　　　　　　　　　　　　　　　　　　　　　物件导向程式设计.　
　　　　　　　　operator　　　　　　　　　　　　　　　　运算子.　
　　　　　　　　overload　　　　　　　　　　　　　　　　多载（过荷、负载）　　　　　　　　　　　　　　<动词>.　
　　　　　　　　overloading　　　　　　　　　　　　　多载（过荷、负载）　　　　　　　　　　　　　　<名词>.　
　　　　　　　　override　　　　　　　　　　　　　　　　覆盖、改写.　
　　　　　　　　parameter　　　　　　　　　　　　　　　参数.　
　　　　　　　　persistence　　　　　　　　　　　　　持续性（永续性、持固性）　　　　　　　　<名词>.　
　　　　　　　　persistent　object　　　　　　　持续性物件.　
　　　　　　　　pointer　　　　　　　　　　　　　　　　　指标.　
　　　　　　　　polymorphism　　　　　　　　　　　　多型（同名异式）.　
　　　　　　　　precedence　　　　　　　　　　　　　　优先序.　
　　　　　　　　pretty　printer　　　　　　　　　　美编工具.　
　　　　　　　　private　　　　　　　　　　　　　　　　　私有.　
　　　　　　　　protected　　　　　　　　　　　　　　　保护.　
　　　　　　　　prototype　　　　　　　　　　　　　　　原型、函数原型（雏型）.　
　　　　　　　　public　　　　　　　　　　　　　　　　　　公共、公有.　
　　　　　　　　pure　virtual　function　　　纯虚拟函数.　
　　　　　　　　reference　　　　　　　　　　　　　　　参考、参考值.　
　　　　　　　　relation　　　　　　　　　　　　　　　　关系.　
　　　　　　　　return　value　　　　　　　　　　　　传回值.　
　　　　　　　　semantics　　　　　　　　　　　　　　　语意.　
　　　　　　　　signature　　　　　　　　　　　　　　　签名、型态签名.　
　　　　　　　　smart　pointer　　　　　　　　　　　聪明的指标.　
　　　　　　　　specialization　　　　　　　　　　特异化、特殊化.　
　　　　　　　　statement　　　　　　　　　　　　　　　陈述、指令（指述）.　
　　　　　　　　static　　　　　　　　　　　　　　　　　　静态.　
　　　　　　　　structure　　　　　　　　　　　　　　　结构、记录.　
　　　　　　　　subclass　　　　　　　　　　　　　　　　子类别、子代类别.　
　　　　　　　　subtype　　　　　　　　　　　　　　　　　子型别、子型态.　
　　　　　　　　superclass　　　　　　　　　　　　　　父类别、亲代类别.　
　　　　　　　　syntax　　　　　　　　　　　　　　　　　　语法、文法.　
　　　　　　　　template　　　　　　　　　　　　　　　　样版（模版）.　
　　　　　　　　throw　　　　　　　　　　　　　　　　　　　丢出.　
　　　　　　　　type　　　　　　　　　　　　　　　　　　　　型态、型别.　
　　　　　　　　virtual　　　　　　　　　　　　　　　　　虚拟.　
　　　　　　　　virtual　function　　　　　　　　虚拟函数.　

[此贴子已经被作者于2006-12-27 21:51:25编辑过]

为什麽　C++　不替　"new"　及　"delete"　搭配个　"realloc()"　？　
　
避免你产生意外。　
　
当　realloc()　要拷贝配置区时，它做的是「逐位元　bitwise」的拷贝，这会弄坏大　
部份的　C++　物件。不过　C++　的物件应该要能自我拷贝才对：用它们自己的拷贝建构　
子或设定运算子。

万一我忘了将　"[]"　用在　"delete"　由　"new　Fred[n]"　配置到的阵列，会发生　
　　　　　 什麽事？　
　
灾难。　
　
这是程式者的－－而不是编译器的－－责任，去确保　new[]　与　delete[]　的正确配　
对。若你弄错了，编译器不会产生任何编译期或执行期的错误讯息。堆积（heap）被　
破坏是最可能的结局，或是更糟的，你的程式会当掉。　

我该怎麽用　new　来配置多维阵列？　
　
有很多方法，端视你对阵列大小的伸缩性之要求而定。极端一点的情形，如果你在编　
译期就知道所有阵列的维度，你可以静态地配置（就像　C　一样）：　
　
　　　　　　　　 class　Fred　{　/*...*/　};　
　
　　　　　　　　 void　manipulateArray()　
　　　　　　　　 {　
　　　　　　　　　　 Fred　matrix[10][20];　
　
　　　　　　　　　　 //使用　matrix[i][j]...　
　
　　　　　　　　　　 //不须特地去释放该阵列　
　　　　　　　　 }　
　
另一个极端情况，如果你希望该矩阵的每个小块都能不一样大，你可以在自由记忆体　
里配置之：　
　
　　　　　　　　 void　manipulateArray(unsigned　nrows,　unsigned　ncols[])　
　　　　　　　　 //'nrows'　是该阵列之列数。　
　　　　　　　　 //所以合法的列数为　(0,　nrows-1)　开区间。　
　　　　　　　　 //'ncols[r]'　则是　'r'　列的行数　('r'　值域为　[0..nrows-1])。　
　　　　　　　　 {　
　　　　　　　　　　 Fred**　matrix　=　new　Fred*[nrows];　
　　　　　　　　　　 for　(unsigned　r　=　0;　r　<　nrows;　++r)　
　　　　　　　　　　　　 matrix[r]　=　new　Fred[　ncols[r]　];　
　
　　　　　　　　　　 //使用　matrix[i][j]...　
　
　　　　　　　　　　 //释放就是配置的反动作：　
　　　　　　　　　　 for　(r　=　nrows;　r　>　0;　--r)　
　　　　　　　　　　　　 delete　[]　matrix[r-1];　
　　　　　　　　　　 delete　[]　matrix;　
　　　　　　　　 }　

怎样确保某类别的物件都是用　"new"　建立的，而非区域或整体／静态变数？　
　
确定该类别的建构子都是　"private:"　的，并定义个　"friend"　或　"static"　函数，　
来传回一个指向由　"new"　建造出来的物件（把建构子设成　"protected:"，如果你想　
要有衍生类别的话）。　
　
　　　　　　　　 class　Fred　{　　　　//只允许　Fred　动态地配置出来　
　　　　　　　　 public:　
　　　　　　　　　　 static　Fred*　create()　　　　　　　　　　　　　　　　　{　return　new　Fred();　　　　　}　
　　　　　　　　　　 static　Fred*　create(int　i)　　　　　　　　　　　　{　return　new　Fred(i);　　　　}　
　　　　　　　　　　 static　Fred*　create(const　Fred&　fred)　{　return　new　Fred(fred);　}　
　　　　　　　　 private:　
　　　　　　　　　　 Fred();　
　　　　　　　　　　 Fred(int　i);　
　　　　　　　　　　 Fred(const　Fred&　fred);　
　　　　　　　　　　 virtual　~Fred();　
　　　　　　　　 };　
　
　　　　　　　　 main()　
　　　　　　　　 {　
　　　　　　　　　　 Fred*　p　=　Fred::create(5);　
　　　　　　　　　　 ...　
　　　　　　　　　　 delete　p;　
　　　　　　　　 }　

如果建构子会丢出例外的话，该怎麽处理它的资源？　
　
物件里面的每个资料成员，都该自己收拾残局。　
　
如果建构子丢出一个例外的话，该物件的解构子就“不会”执行。如果你的物件得回　
复些曾做过的事情（像是配置记忆体、开启档案、锁定　semaphore），该物件内的资　
料成员就“必须”记住这个「必须恢复的东西」。　
　
举例来说：不要单单的把配置到的记忆体放入　"Fred*"　资料成员，而要放入一个「　
聪明的指标」(smart　pointer)　资料成员中；当该“聪明指标”死掉的话，它的解构　
子就会删去　Fred　物件

我该早一点还是晚一点让东西有常数正确性？　
　
越越越早越好。　
　
延後补以常数正确性，会导致雪球效应：每次你在「这儿」用了　"const"，你就得在　
「那儿」加上四个以上的　"const"。　

若我想在　"const"　成员函数内更新一个「看不见的」资料成员，该怎麽做？　
　
使用　"mutable"　或是　"const_cast"。　
【译注】这是很新的　ANSI　C++　RTTI　(RunTime　Type　Information)　规定，Borland　
　　　　　　　　 C++　4.0　就率先提供了　const_cast　运算子。　
　
少数的查询子需要对资料成员做些无害的改变（譬如："Set"　物件可能想快取它上一　
回所查到的东西，以加速下一次的查询）。此改变「无害」是指：此改变不会由物件　
的外部介面察觉出来（否则，该运作行为就该叫做更动子，而非查询子了）。　
　
这类情况下，会被更动的资料成员就该被标示成　"mutable"（把　"mutable"　关键字　
放在该资料成员宣告处前面；也就是和你放　"const"　一样的地方），这会告诉编译　
器：此资料成员允许　const　成员函数改变之。若你不能用　"mutable"　的话，可以用　
"const_cast"　把　"this"　的「常数性」给转型掉。譬如，在　"Set::lookup()　const"　
里，你可以说：　
　
　　　　　　　　 Set*　self　=　const_cast(this);　
　
这行执行之後，"self"　的位元内容就和　"this"　一样（譬如："self==this"），但　
是　"self"　是一个　"Set*"　而非　"const　Set*"　了，所以你就可以用　"self"　去修改　
"this"　指标所指向的物件。　

「继承」对　C++　来说很重要吗？　
　
是的。　
　
「继承」是抽象化资料型态（abstract　data　type,　ADT）与　OOP　的一大分野。　

怎样在　C++　中表现出继承？　
　
用　":　public"　语法：　
　
　　　　　　　　 class　Car　:　public　Vehicle　{　
　　　　　　　　　　　　　　　　 //^^^^^^^^----　":　public"　读作「是一种」("is-a-kind-of-a")　
　　　　　　　　　　 //...　
　　　　　　　　 };　
　
我们以几种方式来描述上面的关系：　
　
　 *　Car　是「一种」("a　kind　of　a")　Vehicle　
　 *　Car　乃「衍生自」("derived　from")　Vehicle　
　 *　Car　是个「特异化的」("a　specialized")　Vehicle　
　 *　Car　是　Vehicle　的「子类别」("subclass")　
　 *　Vehicle　是　Car　的「基底类别」("base　class")　
　 *　Vehicle　是　Car　的「父类别」("superclass")　（这不是　C++　界常用的说法）　
　　　 【译注】"superclass"　是　Smalltalk　语言的关键字。　
　

Derived*　-->　Base*　是正常的；那为什麽　Derived**　-->　Base**　则否？　
　
C++　让　Derived*　能转型到　Base*，是因为衍生的物件「是一种」基底的物件。然而　
想由　Derived**　转型到　Base**　则是错误的！要是能够的话，Base**　就可能会被解　
参用（产生一个　Base*），该　Base*　就可能指向另一个“不一样的”衍生类别，这　
是不对的。　
　
照此看来，衍生类别的阵列就「不是一种」基底类别的阵列。在　Paradigm　Shift　公　
司的　C++　训练课程里，我们用底下的例子来比喻：　
　
　　　　　　　　　　　　　　　 "一袋苹果「不是」一袋水果".　
　　　　　　　　　　　　　　　 "A　bag　of　apples　is　NOT　a　bag　of　fruit".　
　
如果一袋苹果可以当成一袋水果来传递，别人就可能把香蕉放到苹果袋里头去！　

什麽是「虚拟成员函数」？　
　
虚拟函数可让衍生的类别「取代」原基底类别所提供的运作。只要某物件是衍生出来　
的，就算我们是透过基底物件的指标，而不是以衍生物件的指标来存取该物件，编译　
器仍会确保「取代後」的成员函数被呼叫。这可让基底类别的演算法被衍生者所替换　
，即使我们不知道衍生类别长什麽样子。　
　
注意：衍生的类别亦可“部份”取代（覆盖，override）掉基底的运作行为（如有必　
要，衍生类别的运作行为亦可呼叫它的基底类别版本）

衍生类别能否将基底类别的非虚拟函数覆盖（override）过去？　
　
可以，但不好。　
　
C++　的老手有时会重新定义非虚拟的函数，以提升效率（换一种可能会运用到衍生类　
别才有的资源的作法），或是用以避开遮蔽效应（hiding　rule，底下会提，或是看　
看　ARM　["Annotated　Reference　Manual"]　sect.13.1），但是用户的可见性效果必　
须完全相同，因为非虚拟的函数是以指标／参考的静态型别为分派（dispatch）的依　
据，而非以指到的／被参考到的物件之动态型别来决定。　
　

我该遮蔽住由基底类别继承来的公共成员函数吗？　
　
绝对绝对绝对绝对不要这样做！　
　
想去遮蔽（删去、撤消）掉继承下来的公共成员函数，是个很常见的错误。这通常是　
脑袋塞满了浆糊的人才会做的傻事。

对「圆形是／不是一种椭圆」这两难问题，有没有其他说法？　
　
如果你说：椭圆都可以不对称地挤压，又说：圆形是一种椭圆，又说：圆形不能不对　
称地挤压下去，那麽很明显的，你说过的某句话要做修正（老实说，该取消掉）。所　
以你不是得去掉　"Ellipse::setSize(x,y)"，去掉圆形和椭圆间的继承关系，就是得　
承认你的「圆形」不一定是正圆。　
　
这儿有两个　OO/C++　新手最易落入的陷阱。他们想用程式小技巧来弥补差劲的事前设　
计（他们重新定义　Circle::setSize(x,y)，让它丢出一个例外，呼叫　"abort()"　，　
或是选用两参数的平均数，或是不做任何事情），不幸的，这些技俩都会让使用者感　
到吃惊：他们原本都预期　"width()　==　x"　和　"height()　==　y"　这两个事实会成立。　
　
唯一合理的做法似乎是：降低椭圆形　"setSize(x,y)"　的保证事项（譬如，你可以改　
成：「这运作行为“可能”会把　width()　设成　x、height()　设成　y，也可能“不做　
任何事”」）。不幸的，这样会把界限冲淡，因为使用者没有任何有意义的物件行为　
足以依靠，整个类别阶层也就无毫价值可言了（很难说服别人去用一个：问你说它是　
做什麽的，你却只会耸耸肩膀说不知道的物件）。

当我改变了内部的东西，怎样避免子类别被破坏？　
　
物件类别有两个不同的介面，提供给不同种类的用户：　
　 *　"public:"　介面用以服务不相关的类别。　
　 *　"protected:"　介面用以服务衍生的类别。　
　
除非你预期所有的子类别都会由你们的工作小组建出来，否则你应该将基底类别的资　
料位元内容放在　"private:"　处，用　"protected:"　行内存取函数来存取那些资料。　
这样的话，即使基底类别的私有资料改变了，衍生类别的程式也不会报废，除非你改　
变了基底类别的　protected　处的存取函数。

衍生类别的解构子应该外显地呼叫基底的解构子吗？　
　
不要，绝对不要外显地呼叫解构子（「绝对不要」指的是「几乎完全不要」）。　
　
衍生类别的解构子（不管你是否明显定义过）会“自动”去呼叫成员物件的、以及基　
底类别之子物件的解构子。成员物件会以它们在类别中出现的相反顺序解构，接下来　
是基底类别的子物件，以它们出现在类别基底列表的相反顺序解构之。　
　
只有在极为特殊的情况下，你才应外显地呼叫解构子，像是：解构一个由「新放入的　
new　运算子」配置的物件。

「私有继承」和「成份」(composition)　有多类似？　
　
私有继承是「成份」(has-a)　的一种语法变形。　
　
譬如：「汽车有引擎」("car　has-a　engine")　关系可用成份来表达：　
　
　　　　　　　　 class　Engine　{　
　　　　　　　　 public:　
　　　　　　　　　　 Engine(int　numCylinders);　
　　　　　　　　　　 void　start();　　　　　　　　　　　　　　　　　//starts　this　Engine　
　　　　　　　　 };　
　
　　　　　　　　 class　Car　{　
　　　　　　　　 public:　
　　　　　　　　　　 Car()　:　e_(8)　{　}　　　　　　　　　　　　　//initializes　this　Car　with　8　cylinders　
　　　　　　　　　　 void　start()　{　e_.start();　}　　//start　this　Car　by　starting　its　engine　
　　　　　　　　 private:　
　　　　　　　　　　 Engine　e_;　
　　　　　　　　 };　
　
同样的　"has-a"　关系也可用私有继承来表达：　
　
　　　　　　　　 class　Car　:　private　Engine　{　
　　　　　　　　 public:　
　　　　　　　　　　 Car()　:　Engine(8)　{　}　　　　　　　　　//initializes　this　Car　with　8　cylinders　
　　　　　　　　　　 Engine::start;　　　　　　　　　　　　　　　　//start　this　Car　by　starting　its　engine　
　　　　　　　　 };　
　
这两种型式的成份有几分相似性：　
　 *　这两种情况之下，Car　只含有一个　Engine　成员物件。　
　 *　两种情况都不能让（外界）使用者由　Car*　转换成　Engine*　。　
　
也有几个不同点：　
　 *　如果你想要让每个　Car　都含有数个　Engine　的话，就得用第一个型式。　
　 *　第二个型式可能会导致不必要的多重继承（multiple　inheritance）。　
　 *　第二个型式允许　Car　的成员从　Car*　转换成　Engine*　。　
　 *　第二个型式可存取到基底类别的　"protected"　成员。　
　 *　第二个型式允许　Car　覆盖掉　Engine　的虚拟函数。　
　
注意：私有继承通常是用来获得基底类别　"protected:"　成员的存取权力，但这通常　
只是个短程的解决方案。　

我应该用指标转型方法，把「私有」衍生类别转成它的基底吗？　
　
当然不该。　
　
以私有衍生类别的运作行为、夥伴来看，从它上溯到基底类别的关系为已知的，所以　
从　PrivatelyDer*　往上转换成　Base*（或是从　PrivatelyDer&　到　Base&）是安全的　
；强制转型是不需要也不鼓励的。　
　
然而用　PrivateDer　的人应该避免这种不安全的转换，因为此乃立足於　PrivateDer　
的　"private"　决定，这个决定很容易在日後不经察觉就改变了。　
　

"private"　和　"protected"　的存取规则是什麽？　
　
拿底下这些类别当例子：　
　
　　　　　　　　 class　B　　　　　　　　　　　　　　　　　　　　{　/*...*/　};　
　　　　　　　　 class　D_priv　:　private　　　B　{　/*...*/　};　
　　　　　　　　 class　D_prot　:　protected　B　{　/*...*/　};　
　　　　　　　　 class　D_publ　:　public　　　　B　{　/*...*/　};　
　　　　　　　　 class　UserClass　　　　　　　　　　　　{　B　b;　/*...*/　};　
　
没有一个子类别能存取到　B　的　private　部份。　
在　D_priv　内，B　的　public　和　protected　部份都变成　"private"。　
在　D_prot　内，B　的　public　和　protected　部份都变成　"protected"。　
在　D_publ　内，B　的　public　部份还是　public，protected　还是　protected　
　 (D_publ　is-a-kind-of-a　B)　。　
Class　"UserClass"　只能存取　B　的　public　部份，也就是：把　UserClass　从　B　那　
儿封起来了。　
　
欲把　B　的　public　成员在　D_priv　或　D_prot　内也变成　public，只要在该成员的名　
字前面加上　"B::"。譬如：想让　"B::f(int,float)"　成员在　D_prot　内也是　public　
的话，照这样写：　
　
　　　　　　　　 class　D_prot　:　protected　B　{　
　　　　　　　　 public:　
　　　　　　　　　　 B::f;　　　　//注意：不是写成　"B::f(int,float)"　
　　　　　　　　 };　
　

ABC　("abstract　base　class")　是什麽？　
　
在设计层面，ABC　对应到抽象的概念。如果你问机械师父说他修不修运输工具，他可　
能会猜你心中想的到底是“哪一种”运输工具，他可能不会修理太空梭、轮船、脚踏　
车、核子潜艇。问题在於：「运输工具」是个抽象的概念（譬如：你建不出一辆「运　
输工具」，除非你知道要建的是“哪一种”）。在　C++，运输工具类别可当成是一个　
ABC，而脚踏车、太空梭……等等都当做它的子类别（轮船“是一种”运输工具）。　
在真实世界的　OOP　中，ABC　观念到处都是。　
　
在程式语言层面，ABC　是有一个以上纯虚拟成员函数（pure　virtual）的类别（详见　
下一则　FAQ），你无法替一个　ABC　建造出物件（案例）来。

怎样替整个类别阶层提供列印的功能？　
　
提供一个　friend　operator<<　去呼叫　protected　的虚拟函数：　
　
　　　　　　　　 class　Base　{　
　　　　　　　　 public:　
　　　　　　　　　　 friend　ostream&　operator<<　(ostream&　o,　const　Base&　b)　
　　　　　　　　　　　　 {　b.print(o);　return　o;　}　
　　　　　　　　　　 //...　
　　　　　　　　 protected:　
　　　　　　　　　　 virtual　void　print(ostream&　o)　const;　　//或　"=0;"　若　"Base"　是个　ABC　
　　　　　　　　 };　
　
　　　　　　　　 class　Derived　:　public　Base　{　
　　　　　　　　 protected:　
　　　　　　　　　　 virtual　void　print(ostream&　o)　const;　
　　　　　　　　 };　
　
这样子所有　Base　的子类别只须提供它们自己的　"print(ostream&)　const"　成员函　
数即可（它们都共用　"<<"　operator）。这种技巧让夥伴像是有了动态系结的能力。　

虚拟建构子　(virtual　constructor)　是什麽？　
　
一种让你能做些　C++　不直接支援的事情之惯用法。　
　
欲做出虚拟建构子的效果，可用个虚拟的　"createCopy()"　成员函数（用来做为拷贝　
建构子），或是虚拟的　"createSimilar()"　成员函数（用来做为预设建构子）。　
　
　　　　　　　　 class　Shape　{　
　　　　　　　　 public:　
　　　　　　　　　　 virtual　~Shape()　{　}　　　　　　　　　　//详见　"virtual　destructors"　
　　　　　　　　　　 virtual　void　draw()　=　0;　
　　　　　　　　　　 virtual　void　move()　=　0;　
　　　　　　　　　　 //...　
　　　　　　　　　　 virtual　Shape*　createCopy()　const　=　0;　
　　　　　　　　　　 virtual　Shape*　createSimilar()　const　=　0;　
　　　　　　　　 };　
　
　　　　　　　　 class　Circle　:　public　Shape　{　
　　　　　　　　 public:　
　　　　　　　　　　 Circle*　createCopy()　　　　const　{　return　new　Circle(*this);　}　
　　　　　　　　　　 Circle*　createSimilar()　const　{　return　new　Circle();　}　
　　　　　　　　　　 //...　
　　　　　　　　 };　
　
执行了　"Circle(*this)"　也就是执行了拷贝建构的行为（在这些运作行为中，　
"*this"　的型态为　"const　Circle&"）。"createSimilar()"　亦类似，但它乃建构出　
一个“预设的”Circle。　
　
这样用的话，就如同有了「虚拟建构子」(virtual　constructors)：　
　
　　　　　　　　 void　userCode(Shape&　s)　
　　　　　　　　 {　
　　　　　　　　　　 Shape*　s2　=　s.createCopy();　
　　　　　　　　　　 Shape*　s3　=　s.createSimilar();　
　　　　　　　　　　 //...　
　　　　　　　　　　 delete　s2;　　　　//　该解构子必须是　virtual　才行!!　
　　　　　　　　　　 delete　s3;　　　　//　如上.　
　　　　　　　　 }　

程式撰写标准是必要的吗？有它就够了吗？　
　
程式撰写标准不会让不懂　OO　的人变懂；只有训练及经验才有可能。如果它有用处的　
话，那就是抑制住那些琐碎无关紧要的程式片段－－当大机构想把零散的程式设计组　
织整合起来时，这些片段常常会出现。　
　
但事实上你要的不光是这种标准而已。它们提供的架构让新手少去担心一些自由度，　
但是系统化的方法论会比这些好看的标准做得更好。组织机构需要的是一致性的设计　
与实行“哲学”，譬如：强型别或弱型别？用指标还是参考介面？　stream　I/O　还是　
stdio？　C++　程式该不该呼叫　C　的？反过来呢？　ABC　该怎麽用？继承该用为实作的　
技巧还是特异化的技巧？该用哪一种测试策略？一一去检查吗？该不该为每个资料成　
员都提供一致的　"get"　和　"set"　介面？介面该由外往内还是由内往外设计？错误状　
况该用　try/catch/throw　还是传回值来处理？……等等。　
　
我们需要的是详细的“设计”部份的「半标准」。我推荐一个三段式标准：训练、谘　
询顾问以及程式库。训练乃提供「密集教学」，谘询顾问让　OO　观念深刻化，而非仅　
仅是被教过而已，高品质的程式库则是提供「长程的教学」。上述三种培训都有很热　
门的市场景况。（【译注】无疑的，这是指美、加地区。）接受过上述培训的组织都　
有如此的忠告：「买现成的吧，不要自己硬干　(Buy,　Don't　Build.)。」买程式库，　
买训练课程，买开发工具，买谘询顾问。想靠自学来达到成功的工具厂商及应用／系　
统厂商，都会发现成功很困难。　
　
【译注】这一段十分具有参考价值。不过有些背景资料得提供给各位参考。别忘了：　
　　　　　　　　 作者是美国人，是以该地为背景，且留意一下他所服务的公司是做什麽的..　
　　　　　　　　 ...　:-)　　　唉！国内有这麽多的专业顾问公司吗？　:-<　
　
少数人会说：程式撰写标准只是「理想」而已，但在上述的组织机构中，它仍有其必　
要性。　
　
底下的　FAQs　提供一些基本的指导惯例及风格。　

我该在函数中间或是开头来宣告区域变数？　
　
在第一次用到它的地方附近。　
　
物件在宣告的时候就会被初始化（被建构）。如果在初始化物件的地方没有足够的资　
讯，直到函数中间才有的话，你可以在开头处初始个「空值」给它，等以後再「设定　
」其值；你也可以在函数中间再初始个正确的东西给它。以执行效率来说，一开始就　
让它有正确的值，会比先建立它，搞一搞它，之後再重建它来得好。以像　"String"　
这种简单的例子来看，会有　350%　的速度差距。在你的系统上可能会不同；当然整个　
系统可能不会降低到　300+%，但是“一定”会有不必要的性能衰退现象。　
　
常见的反驳是：「我们会替物件的每个资料提供　"set"　运作行为，则建构时的额外　
耗费就会分散开来。」这比效能负荷更糟，因为你添加了维护的梦靥。替每个资料提　
供　"set"　运作行为就等於对资料不设防：你把内部实作技巧都显露出来了。你隐藏　
到的只有成员物件的实体“名字”而已，但你用到的　List、String　和　float（举例　
来说）型态都曝光了。通常维护会比　CPU　执行时间耗费的资源更多。　
　
区域变数应该在靠近它第一次用到之处宣告。很抱歉，这和　C　老手的习惯不同，但　
是「新的」不见得就是「不好的」。