C++ 在頭文件中包含 STL

Question

在頭文件中包含 STL 是壞主意還是好主意？ 其中您將它們用作您自己定義的類的成員變量。

我的假設是，有些人真的希望他們創建的庫非常獨立於 C++ 標准庫。 因此，他們被迫再次重寫類似於 C++ STL 中可用功能的類型，而其他人則嘗試在其頭文件中轉發聲明稍后需要的類型。 其他人認為這是一種不好的做法，根本不是一個好主意。

如果我錯了，請糾正我（我知道的不多，這就是為什么一切都只是假設）：

1. 那么在前向聲明 STL 上可用的類型時，代碼可移植性（對於那些真正希望他們的代碼獨立於平台的人）有什么影響？（我只知道 MSDN 建議的一種類型的vector可以被前向聲明，但是不能保證一直工作）。

2. 如果我在頭文件中包含 STL，可能存在什么問題？ 這會影響我的代碼的可移植性嗎？

3. 如果我在我的 DLL 的頭文件中包含 STL 並將該 DLL 帶入其他計算機，我會遇到什么問題？

4. 而且，你能給我一個啟示，為什么我應該（不應該）在我的標題中包含 STL？

Answer 1

使用 PIMPL 習慣用法在公開/導出 STL 類型的標頭上創建編譯防火牆： 詳細信息

class MyList{
public:
//Some functions
private:
std::vector<int> _content;
};

如果您在 Vs2012 中創建 MyList 但組件是在 VS2008 中構建的，那么 VS2008 中的代碼將期望按照 STL 2008 的內存布局，但布局將是 STL 2012 的布局。這將產生一系列問題。

1. 您的組件不能跨編譯器移植，更不用說平台了。 例如，使用 std::vector 作為成員變量在 VS2008 中構建的組件將具有與在 VS2012 中編譯的相同大小不同的大小。
2. 是的，在大多數情況下，您的代碼將在編譯器之間兼容，除非您使用舊版本中更新的 STL 功能。
3. 只要您在另一台計算機上有 dll 的運行時就沒有問題。
4. 對於可重用代碼，您不應該跨 dll/組件邊界使用 stl 類型。

Answer 2

那么在前向聲明 STL 上可用的類型時，代碼可移植性（對於那些真正希望他們的代碼獨立於平台的人）有什么影響？

始終使用標准 C++ 和標准庫是可移植性的標志。

如果我在頭文件中包含 STL，可能存在什么問題？ 這會影響我的代碼的可移植性嗎？

也許更長的編譯時間？ 再次，請參閱上面的答案。

如果我在我的 DLL 的頭文件中包含 STL 並將該 DLL 帶入其他計算機，我會遇到什么問題？

大多數情況下和 AFAIK，DLL 僅“存儲”您的類的方法定義。 您仍然需要在.h文件中包含 STL 頭文件。

而且，你能給我一個啟示，為什么我應該（不應該）在我的標題中包含 STL？

你應該，因為你幾乎總是想使用 STL。 來到Lounge<C++> ，您一定會大開眼界。

Answer 3

如果您使用的是標准 C++ STL 庫，那么您可能不會遇到移植問題，因為 Microsoft Visual C++ 和 g++ 都支持這些。 除非您使用非標准 STL 標頭，否則您將遇到問題。

Answer 4

不惜一切代價避免標頭中的 STL：

1. STL 充滿了實現細節。 把它留給源代碼。
2. 標頭是您的 API，您只想公開函數、結構和接口。
3. 您可能希望以不同的模式編譯和鏈接庫 - 如果您說在調試中分配並在發布中刪除內存，則會導致跨模塊錯誤。 所以不要使用 std::string 在 API 中傳遞信息。
4. 一個你開始只包含來自 STL 的一個頭文件，你會發現其他模塊開始泄漏。你最終會被 STL 毒化，沒有真正的界面，構建時間在幾分鍾內，而它應該在幾秒鍾內。

STL 將如何改進以下 API？ IDog 的消費者不需要知道狗的內部結構，只需要知道它會吠叫。

struct IDog
{
     virtual void Bark() = 0;
     virtual void Free() = 0;
}

IDog* CreateDog(); 

In your source code you might have

struct Dog: IDog
{
    Dog() {...}
    std::vector<VocalChord> vocalChords; 
    void Bark() override { Resonate(vocalChords); }
    void Free() { delete this; }
};

IDog* CreateDog() { return new Dog(); }