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(); }