c++非局部靜態數據實例分析

本篇內容介紹了“c++非局部靜態數據實例分析”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

靜態數據包括：

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根本就不會被產生！完美！通過這樣的設計，我們反手一勾拳同時解決了兩個問題：既保證了初始化的次序，由提高了程序的性能。

“c++非局部靜態數據實例分析”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！