C++類庫設(shè)計的基本思想和方法

這一篇文章我們來討論一下關(guān)于C++類庫設(shè)計的一般性的指導思想和方法。

首先說指導思想。這是一個價值觀問題，我們在此提出三條標準：簡單，高性能，可移植。

我們在開篇就對簡單性目標作了敘述，這里再稍微展開討論一下。我們提出的簡單標準，首先是外部接口簡單，其次是內(nèi)部結(jié)構(gòu)簡單。我們知道，類庫是提供給上層應用程序使用的，也就是按照一定的接口規(guī)范，向上層提供一定的功能服務。接口設(shè)計得越簡單，對上層用戶來說就越方便，就越不容易產(chǎn)生Bug。我們可以注意到，流行的成功類庫都是擁有簡單接口的。為了使接口簡單，常常不得不把有關(guān)具體實現(xiàn)的復雜性封裝于類庫內(nèi)部，也就是說，關(guān)于簡單性的設(shè)計原則，外部接口簡單優(yōu)先于內(nèi)部實現(xiàn)簡單。

高性能是C++語言優(yōu)于其它OO語言的一個特性。C++的高性能應該首先歸于它運行模式，和大多數(shù)OO語言不同，C++程序編譯后直接產(chǎn)生本地平臺代碼（Native Code），理論上具備了可能的最大執(zhí)行性能。另外的一個原因是主流的C++編譯器都被設(shè)計得非常精巧，具有優(yōu)越的代碼優(yōu)化能力。對于C++類庫設(shè)計者來說，保持C++的高性能是一個重要目標。程序的高性能可以從兩方面來評價，一是時間性能，以盡量短的時間來解決盡量多的業(yè)務；二是資源性能，以盡量少的資源消耗，包括CPU使用、內(nèi)存占用、網(wǎng)絡(luò)流量、磁盤空間等等，來維持正常的程序功能。提高性能的主要手段是數(shù)據(jù)結(jié)構(gòu)、算法和程序體現(xiàn)結(jié)構(gòu)的優(yōu)化設(shè)計。

再說可移植性。C++的編譯后輸出代碼是本地平臺代碼，因此C++本身不具有目標代碼可移植性，C++的可移植性只能是源代碼可移植性。源代碼的可移植性是指，同一軟件產(chǎn)品的全部或者部分源代碼可以在不同的編譯環(huán)境中進行編譯（不需要編譯的除外），并且其結(jié)果具有相同的品質(zhì)特性（依優(yōu)先順序包括功能性、可靠性、可用性、性能性、可維護性等）。編譯環(huán)境可以大致分為三個層次，最底層的是操作系統(tǒng)，也就是平臺（Platform），其次是對源代碼直接進行處理的編譯器，然后是其它在編譯過程中必需的中間件物品，如庫文件等。我們知道C++雖然在語言規(guī)范上獲得了統(tǒng)一（ISO/IEC），其編譯器卻是群雄割據(jù)的局面，具有代表性的有Borland C++系列（已經(jīng)淡出市場），Microsoft的Visual Studio系列的C++編譯器和GNU陣營的壓軸產(chǎn)品gc中的g++。源代碼經(jīng)編譯環(huán)境處理后產(chǎn)生的可執(zhí)行代碼的執(zhí)行平臺稱為目標平臺，不同的編譯器的目標平臺也不同，有的支持多平臺，如g++，有的是單一平臺，如Visual C++。對于類庫設(shè)計者來說，想要獲得完全的可移植性是非常困難的（除非是象STL這樣被納入語言規(guī)范的類庫，因為不支持STL就是不支持標準的C++。即便如此不同的編譯環(huán)境還是存在不同的STL實現(xiàn)版本，造成“一個類庫多個實現(xiàn)”的局面），我們只能有選擇地支持一部分環(huán)境。我們在開篇就已經(jīng)說明，我們選擇g++和Visual C++編譯器，選擇Linux和Windows 32位目標平臺。

接下來我們來討論C++類庫設(shè)計的方法論。

首先，我們采用僅用頭文件的類庫設(shè)計方式（Header-only，STL的大多數(shù)實現(xiàn)版本都是采用Header-only的方式），也就是在頭文件（.h）中聲明和定義類，將其成員函數(shù)全部定義為內(nèi)聯(lián)函數(shù)，而不使用源程序文件（.cpp）。

我們知道在C語言的開發(fā)環(huán)境中，所謂庫文件包含兩個部分，頭文件部分和二進制文件部分。根據(jù)二進制文件和用戶目標文件結(jié)合方式的不同，又可分為靜態(tài)鏈接文件和動態(tài)鏈接文件。這種庫的構(gòu)成模式已成為事實上的C語言開發(fā)環(huán)境的標準，絕大多數(shù)平臺、絕大多數(shù)編譯器都使用這種模式。

然而C++語言開發(fā)環(huán)境，這種庫構(gòu)成模式遭遇到一個重大問題，就是符號命名問題。舉例來說，C++允許多個函數(shù)可以被重載(Overload)，可以具有相同的名稱，而通過參數(shù)列表不同被予以區(qū)別。這樣就帶來一個問題，編譯完成的目標代碼中怎樣來區(qū)別這些在源代碼中具有相同名稱的函數(shù)？常見的做法是在編譯器輸出的函數(shù)的符號名稱中加入描述類型信息的字符串，這種方法通常被稱為名稱裝飾（Name decoration）或者名稱糟化（Name mangling，這個術(shù)語真不好翻譯，筆者的感覺是發(fā)明這個詞的人覺得編譯器把本來簡單干凈的符號給搞亂了）。比如說，g++3.4.4對于函數(shù)void func(int),其編譯輸出符號名稱為_Z1funci，對于函數(shù)void func(int, int)，其輸出符號名稱為_Z1funcii，等等。但是，這種名稱裝飾規(guī)則沒有統(tǒng)一規(guī)范，也就是說不同的編譯器有各自不同的名稱裝飾規(guī)則，這樣就導致不同的C++編譯器只能識別自己的輸出文件，而沒有辦法處理其他編譯器的輸出文件。因此，如果將C++程序制作成二進制的庫文件，則其能夠支持的開發(fā)環(huán)境只能限于原始的開發(fā)環(huán)境，基本上不具有多種開發(fā)環(huán)境間的通用性。

一個解決辦法是將庫文件保持在源代碼形態(tài)（包括頭文件和源文件），而不編譯成二進制文件。比如STL的許多實現(xiàn)版本都是以頭文件形式存在。這樣雖然解決了名稱裝飾所帶來的不可移植問題，但同時又會帶來代碼編譯時間增長，源代碼完全公開等問題。在C++的名稱裝飾規(guī)則未被統(tǒng)一之前，看起來這個問題是很難兩全其美地解決了。

在本系列中，我們也仿照g++的STL實現(xiàn)方式，完全以頭文件形式來編寫類庫。為什么不把代碼放到源文件中去呢？主要原因是，頭文件只需要用戶使用包含指令（#include）就可以處理了，而源文件則需要配置到用戶工程的編譯目標列表中，和用戶的源程序形成共同編譯的形式，破壞了用戶工程的編譯目標的封閉性，比較麻煩而且不符合軟件開發(fā)的一般習慣。

其次我們來討論如何支持多平臺。我們已經(jīng)說過在本系列中我們的線程庫支持Linux平臺的Posix線程和Windows 32位平臺的線程模式。我們可以參考C++的Pimpl“慣語”(Pimpl idiom，在Herb Sutter的《Exceptional C++》中有介紹)，采用2層類構(gòu)造方式。上次類亦即接口類，為用戶提供統(tǒng)一的類接口，在用戶看來具有唯一的類行為定義；下層類亦即實現(xiàn)類，將接口類的行為定義轉(zhuǎn)化為某個平臺的具體實現(xiàn)。