可以在较旧的C ++编译器中链接已编译的C ++ 11库（lib，dll等）吗？

旧的C ++编译器（例如VS2008和gcc3.4）可以与用C ++ 11编写的外部库链接吗？

我的想法是，C ++ 11 .lib文件在此阶段仅是字节代码，并且只要它可以解析和可调用，就不应打扰旧的编译器如何生成它。

我正在开发一个小型库，其API仍应支持C ++ 03用户。因此，展望未来，我想知道是否可以使用诸如此类的有用功能来实现我的库std::unique_ptr，还是我必须坚持使用boost::？

如果您的库仅在其实现中使用C ++ 11，并且不会公开公开C ++ 11的功能或类型，尤其是如果您使用静态链接，那么可以，甚至是标准的。

考虑一个常见的情况，在该情况下，库公开了C级接口（供最广泛的客户端使用），但在内部用C ++实现。链接到此类库的客户端只需要担心公共二进制API（导出的函数），为了获得最大的兼容性，您必须将其限制为旧版C / C ++。Java程序可以链接到在C ++内部实现的C级API。这并不意味着Java需要“支持C ++”。同样，旧式的C / C ++客户端可以链接到内部使用C ++库或任何其他库的某些更先锋版本的C级或C ++级API。两件分开的事情：链接到库的接口需要什么，以及库本身在内部链接（或静态引入）的东西。

您只是不将库的客户端暴露给实现的依赖项。

如果您可以将依赖项（C ++ 11或其他任何东西）静态链接到您的库中，则这是干净且自包含的。该库是一个真正的黑匣子：只有字节码。但是，即使您的库通过“隐式动态”链接链接到依赖项（不要与显式LoadLibrary / GetProcAddress类型以及* nix和OS X上的类似方法相混淆），较旧的客户端仍应该能够链接到该库的公共接口，即使它们无法链接到库所依赖的库。

听起来您想编写一个供其他人使用的新库，并且您想使用C + 11作为实现语言。有许多问题需要考虑：

• 通过引入新版本的C ++，您将需要将新的C ++运行时库与库一起部署，这样可以吗？
• 你应该不是在您的公共接口使用新的C + 11点的类型，否则他们将无法调用它。
• 通常，应避免使用复杂的类型，例如unique_ptr，偶数向量等。除非将库作为源代码分发，否则库中对象的布局可能与客户端代码中的布局不同。坚持使用没有对象布局变化风险的简单类型。