非局部靜態數據在多編譯單元中的窘境

標題有點拗口，先來解釋一下。

靜態數據包括：

1. 在namespace內定義的名字空間域變量 √
2. 在類中被聲明爲static的類域變量 √
3. 在函數中被聲明爲static的局部靜態變量 ×
4. 在文件中被定義的全局變量（不管有沒有static修飾） √

上面提到的非局部靜態數據指的就是除去第3種情形之外，其他的1、2、4情形。

而編譯單元指的就是.o文件，假如一個工程是由n個單獨的cpp和對應的頭文件，那麼就會被事先編譯生成n個.o文件，有時候我們將這些*.o文件稱爲目標文件，它們作爲生成最後的統一可執行文件，也被稱爲編譯單元。

綜上所言，本文的標題的含義是：如果在多文件中，分別定義了多個靜態數據（不含局部變量），那麼他們之間的相互依賴關係將會出現微妙的窘境。

什麼窘境呢？事情是這樣的，由於靜態數據會在程序運行開始時刻進行初始化（不管是指定初始化，還是系統自動初始化），並且C++標準沒有規定多個文件中的這些靜態數據的初始化次序，這就會帶來一個問題：如果非局部靜態數據相互依賴，那就會因爲初始化次序的不確定性，導致程序的運行結果無法預測。

比如，程序員Jack開發了一個超好用的類，叫car（汽車），並定義了一個此類的對象預備給他人使用。

class car  // 非開源代碼
{
    ... ...
public:
    void startup(params);
    ... ...
};

extern car BMW; // 一臺高性能汽車 ^__^

另一方面，在不同的時間不同的地點，不同的程序員Rose基於不同的目的，開發了一個物流類MF，很自然地會直接使用Jack的汽車對象來完成某些工作。

class MF
{
public:
    MF(params);
    ... ...
};

MF::MF(params)
{
    ... ...
    BMW.startup();  // 使用car對象
}

很快，Rose的代碼便會遇到災難性的後果，因爲C++編譯時無法保證在MF對象初始化之時，汽車對象BMW究竟有沒有初始化完畢。因此，MF很有可能調用了一個未初始化對象的startup函數，這很尷尬。

---

避免這種情況做法也很簡單，那就是定義一個函數，專門用來處理這些引發麻煩的多編譯單元裏的非局部靜態數據。比如：

car &BMW()
{
    static car c; // 局部靜態對象c
    return c;
}

此時，Rose使用car對象的情形只需要一個小小小小的改動：

MF::MF(params)
{
    ... ...
    BMW().startup();  // 使用car對象
}

沒錯，就是在BMW的後面加了一對括號。整體而言，用戶Rose在使用car對象的過程是完全一樣的，但程序的邏輯大有不同，當Rose首次調用函數BMW的時候，局部靜態對象c被創建並初始化，這保證了調用startup()函數的正確性，其次，如果startup()一次都沒被調用過，那麼局部靜態對象c根本就不會被產生！完美！

通過這樣的設計，我們反手一勾拳同時解決了兩個問題：既保證了初始化的次序，由提高了程序的性能。

識別下面二維碼，進入 微店●祕籍酷 逛逛吧！