C++對象可以使用兩種方式進行創(chuàng)建：構(gòu)造函數(shù)和復(fù)制構(gòu)造函數(shù)。假如我們定義了類A，并使用它創(chuàng)建對象。

對象a和b使用編譯器提供的默認構(gòu)造函數(shù)A::A()創(chuàng)建出來，我們稱這種創(chuàng)建方式為對象的定義（包含聲明的含義）。對象c和d則是使用已有的對象，通過編譯器提供的復(fù)制構(gòu)造函數(shù)A::A(const A&)創(chuàng)建，我們稱這種創(chuàng)建方式為對象的初始化（包含定義和聲明的含義）。

可能不少人會把對象的初始化和對象的賦值混淆，比如。

這里把對象d賦值給對象c并非創(chuàng)建新的對象，它不會調(diào)用任何構(gòu)造函數(shù)。編譯器默認提供的賦值運算符重載函數(shù)const A&operator=(const A&)為該語句提供支持。

編譯器除了提供默認構(gòu)造函數(shù)、復(fù)制構(gòu)造函數(shù)和賦值運算符重載函數(shù)之外，有可能還為我們提供了析構(gòu)函數(shù)A::~A()，但是這里的析構(gòu)函數(shù)并不是virtual的（相信會有童鞋忘記這一點）。

這些基礎(chǔ)的語法對學(xué)習(xí)過C++的人或許并不陌生，我們自從學(xué)習(xí)了面向?qū)ο驝++后，一直都知道編譯器為我們提供了這樣的便利條件。經(jīng)過多年的編程實踐和體驗，我們絕對相信編譯器的確為我們做了這些工作，因為我們沒有遇到過任何問題。甚至我們腦子中會默認形成一個概念——即使我定義了一個空類（類內(nèi)什么都沒有），編譯器依然會“乖乖的”為我們生成上邊所說的四個函數(shù)。

如果你真的形成了這種觀念的話，那么恭喜你，因為你已經(jīng)將C++基本規(guī)則運用的十分熟練了。同時遺憾的是你我都看到了冰山一角，編譯器的工作方式遠不像我們使用它的那樣。讀者可能會疑問，難道編譯器沒有生成這些函數(shù)嗎？答：要看你類的定義。那么編譯器到底如何生成這些函數(shù)呢？和我一樣又好奇心的人都想一探究竟，而這些內(nèi)容在《Inside The C++ Object Model》被詮釋的比較徹底。筆者也通過“借花獻佛”的方式將該書所描述的對象構(gòu)造的內(nèi)幕結(jié)合個人的理解和大家一起分享。

首先我們從最簡單的談起，編譯器為類生成構(gòu)造函數(shù)了嗎？如果按照上邊描述的例子，只有一個空的類定義的話，我們可以肯定的說——沒有。對編譯器這樣的做法，我們不必感到驚訝。試想一個空的類——沒有數(shù)據(jù)成員，沒有成員函數(shù)，即使生成了構(gòu)造函數(shù)又能做什么呢？即便是生成了，也只是一個空構(gòu)造函數(shù)而已。

它什么也做不了，也什么都不必做。更“悲劇”，它的出現(xiàn)不僅沒有任何積極意義，還會為編譯器和程序運行增加完全不必要的函數(shù)調(diào)用負擔(dān)。

既然如此，我們讓這個類再復(fù)雜一點，我們?yōu)樗黾訑?shù)據(jù)成員和成員函數(shù)，比如下邊這段代碼（我們記它為例子1）。

即便如此，結(jié)果還是和上邊的一樣，不生成構(gòu)造函數(shù)！因為沒有任何理由對var初始化，況且編譯器也不知道用什么值給它初始化。

果然，在主函數(shù)內(nèi)定義對象a后，沒有任何構(gòu)造函數(shù)被調(diào)用。

有人可能會說用0初始化不行嗎？這只是我們的“一廂情愿”而已。一個沒有初始化的變量本身的值就可以是不確定的，何必要生成一個沒有任何意義的初始化為0的語句呢。

編譯器到底怎樣才能生成構(gòu)造函數(shù)呢？！或許你和我一樣有點“抓狂”了。不過現(xiàn)在還不是絕望的時候，因為編譯器需要我們給它一個“正當(dāng)?shù)睦碛伞鄙蓸?gòu)造函數(shù)。有四個正當(dāng)?shù)睦碛?，讓編譯器不得不生成構(gòu)造函數(shù)，這里一一介紹。

首先，我們修改一下var的類型。這里假設(shè)它不是內(nèi)置類型int，而是一個定義好的類B。

B var;

修改一下數(shù)據(jù)成員的類型為自定義類型能影響編譯器的抉擇嗎？答：可能。這要看類B有沒有定義構(gòu)造函數(shù)。讀者可能有點明白了，是的，如果B沒有定義構(gòu)造函數(shù)（和這里的A一個樣子），那么編譯器仍然沒有理由生成構(gòu)造函數(shù)——為B初始化什么呢？反之，B一旦定義了默認構(gòu)造函數(shù)B::B()，即便它是空的，編譯器就不得不為A創(chuàng)建默認構(gòu)造函數(shù)了（這里不考慮編譯器的深度優(yōu)化）。因為A的對象需要用B的默認構(gòu)造函數(shù)初始化它自己的成員var，雖然B的構(gòu)造函數(shù)什么也沒做。因為編譯器不能假定B的構(gòu)造函數(shù)做了什么樣的操作（極端一點：萬一修改了一個全局變量了呢？），因此編譯器有絕對的必要生成A的構(gòu)造函數(shù)，保證B類型的數(shù)據(jù)成員的構(gòu)造函數(shù)正常執(zhí)行。

轉(zhuǎn)到編譯器為A生成的構(gòu)造函數(shù)處，我們發(fā)現(xiàn)了B的構(gòu)造函數(shù)被調(diào)用的語句（選中行）。

當(dāng)然，如果B提供了構(gòu)造函數(shù)，但不是默認的構(gòu)造函數(shù)，那么必須要程序員介入為var初始化，否則編譯器就不客氣了——error！

因此，編譯器生成默認構(gòu)造函數(shù)的第一個正當(dāng)理由是——類內(nèi)數(shù)據(jù)成員是對象，并且該對象的類提供了一個默認構(gòu)造函數(shù)。

現(xiàn)在，我們回到例子1，這里我們不修改var的類型，而是讓A繼承于另一個類C。

我們都知道，在C++構(gòu)造函數(shù)初始化語法中，構(gòu)造函數(shù)會先初始化基類C，再初始化自身的數(shù)據(jù)成員或者對象。因此，這里的問題和對象成員var類似。如果基類C沒有提供任何構(gòu)造函數(shù)，那么編譯器仍然不提供A的默認構(gòu)造函數(shù)。如果C提供了默認構(gòu)造函數(shù)，結(jié)果和前邊類似。

結(jié)果不出所料，編譯器為A生成了構(gòu)造函數(shù)，并且調(diào)用了基類C定義的默認構(gòu)造函數(shù)。同樣，若C沒有提供默認默認構(gòu)造函數(shù)，而提供了其他構(gòu)造函數(shù)，編譯是無法通過的。

這也是編譯器生成默認構(gòu)造函數(shù)的第二個正當(dāng)理由——類的基類提供了默認的構(gòu)造函數(shù)。

我們再次回到例子1，這次我們修改成員函數(shù)fun。

我們把類A的成員函數(shù)fun修改為虛函數(shù)，再次看看是否產(chǎn)生了默認構(gòu)造函數(shù)。

這次編譯器“毫不客氣”的為A生成了默認構(gòu)造函數(shù)，雖然它沒有調(diào)用任何其他的構(gòu)造函數(shù)！這是什么原因呢？原來，C++為了實現(xiàn)多態(tài)機制，需要為類維護一個虛函數(shù)表（vftable），而每個該類的對象都保存一個指向該虛函數(shù)表的一個指針（一般保存在對象最開始的四個四節(jié)處，多態(tài)機制的實現(xiàn)這里暫不介紹）。編譯器為A生成構(gòu)造函數(shù)，其實不為別的，就為了保證它定義的對象都要正常初始化這個虛函數(shù)表的指針（vfptr）！

好了，因此我們得出編譯器生成默認構(gòu)造函數(shù)的第三個正當(dāng)理由——類內(nèi)定義了虛函數(shù)。這里可能還涉及一個更復(fù)雜點的情況：類內(nèi)本身沒有定義虛函數(shù)，但是繼承了基類的虛函數(shù)。其實按照上述的原則，我們可以推理如下：基類既然定義了虛函數(shù)，那么基類本身就需要生成默認構(gòu)造函數(shù)初始化它本身的虛函數(shù)表指針。而基類一旦產(chǎn)生了默認構(gòu)造函數(shù)，派生類就需要產(chǎn)生默認構(gòu)造函數(shù)調(diào)用它。同時，如果讀者對多態(tài)機制了解清除的話，派生類在生成的默認構(gòu)造函數(shù)內(nèi)還會初始化一次這個虛函數(shù)表指針的。

最后，我們再次回到例子1，這次仍然讓A繼承于C，但是這次C是一個空類——什么都沒有，也不會自動生成默認構(gòu)造函數(shù)。但是A繼承C的方式要變化一下。

A虛繼承于C，這次又有什么不同呢？

這次編譯器也生成了A的構(gòu)造函數(shù)，并且初始化過程和虛函數(shù)時有點類似。細心觀察下發(fā)現(xiàn)，這次構(gòu)造函數(shù)也初始化了一張表——vbtable。了解虛繼承機制的讀者應(yīng)該不會陌生，這張表叫虛基類表，它記錄了類繼承的所有的虛基類子對象在本類定義的對象內(nèi)的偏移位置（至于虛繼承機制的實現(xiàn)，我們以后詳細探討）。為了保證虛繼承機制的正確工作，對象必須在初始化階段維護一個指向該表的一個指針，稱為虛表指針（vbptr）。編譯器因為它提供A的默認構(gòu)造函數(shù)的理由和虛函數(shù)時類似。

這樣，我們得出編譯器生成默認構(gòu)造函數(shù)的第四個正當(dāng)理由——類使用了虛繼承。

到這里，我們把編譯器為類生成默認構(gòu)造函數(shù)的正當(dāng)理由闡述完畢，相信大家應(yīng)該對構(gòu)造函數(shù)的生成時機有了一個大致的認識。這四種“正當(dāng)理由”其實是編譯器不得不為類生成默認構(gòu)造函數(shù)的理由，《Inside The C++ Object Model》里稱這種理由為nontrival的（候sir翻譯的很別扭，所以怎么翻譯隨你啦）。除了這四種情況外，編譯器稱為trival的，也就是沒有必要為類生成默認構(gòu)造函數(shù)。這里討論的構(gòu)造函數(shù)生成準(zhǔn)則的內(nèi)容是寫進C++Standard的，如此看來標(biāo)準(zhǔn)就是“貼合正常思維”的一套準(zhǔn)則（簡單YY一下），其實本就是這樣，編譯器不應(yīng)該為了一致化做一些沒有必要的工作。

通過對默認構(gòu)造函數(shù)的討論，相信大家對復(fù)制構(gòu)造函數(shù)、賦值運算符重載函數(shù)、析構(gòu)函數(shù)的生成時機應(yīng)該可以自動擴展了。沒錯，它們遵循著一個最根本的原則：只有編譯器不得不為這個類生成函數(shù)的時候（nontrival），編譯器才會真正的生成它。

因此，正如標(biāo)題所說，我們不要被C++語法中所描述的那些條條框框所“蒙騙”了。的確，相信這些生成規(guī)則不會對我們的編程帶來多大的影響（不會產(chǎn)生錯誤），但是只有了解它們的背后操作，我們才知道編譯器究竟為我們做了什么，我們才知道如何使用C++才能讓它變得更有效率——比如消除不必要的構(gòu)造和虛擬機制等（如果可以的話）。相信本文對C++自動生成的內(nèi)容的描述讓不少人認清對象構(gòu)造函數(shù)產(chǎn)生的前因后果，希望本文對你有所幫助。

最新評論