如果 C++11 应用程序使用的属于 C++17 库的所有面向公众的标头和 API 都遵循 C+，是否可以针对 C++11 应用程序使用使用 C++17 构建的库+11 语法。 C++17 库的内部实现确实具有 C++17 特定的功能。
是静态链接还是动态链接重要吗？
【问题讨论】：
标签： c++ c++11 c++17 static-linking dynamic-linking
如果 C++11 应用程序使用的属于 C++17 库的所有面向公众的标头和 API 都遵循 C+，是否可以针对 C++11 应用程序使用使用 C++17 构建的库+11 语法。
一般来说，这是灾难的根源。在某些情况下，如果幸运的话，它可能会起作用（例如，如果您不共享更改 ABI 的标准库对象，如果您在使用 API 时没有触发任何 ABI 差异等）。
您想要做的是使用完全相同的编译器编译所有您的代码，包括编译器版本和编译器标志。即使这样，您也应该阅读编译器的文档，以了解有关依赖项和系统依赖项的静态/动态链接的更多可能问题。
C++17 库的内部实现确实具有 C++17 的特定功能。
这不是问题本身（事实上，许多 C++ 库都提供 C 接口），但您需要尊重编译器/平台文档的任何链接限制/问题。
静态链接还是动态链接重要吗？
一样。对于大多数平台，在混合 C++11 和 C++17 的问题上应该不会有任何改变，但您仍然需要处理通常的问题。
【讨论】：
C++ 不保证 ABI 的稳定性/兼容性。因此，您总是必须使用完全相同的编译器编译和链接应用程序的所有部分，并且通常使用相同的编译器选项。 一些编译器有时提供二进制兼容性保证，但不要指望它。在对象之间更改语言标准版本通常很好，但在某些情况下，语言版本之间存在 ABI（或 API）中断。
C++ 语言 不提供任何保证，除非您使用相同的工具以相同的方式编译所有内容。基本上;每次都使用相同的工具和相同的设置或不保证从头开始编译所有内容（这包括您的代码、标准库的代码以及您可能正在使用的任何第三方库的代码） .
【讨论】：
语言未指定。
一般来说，只要您更改编译器版本或任何库的版本（公开或传递），保证就会飞出窗口。您是否可以使用相同的编译器（相同版本）和相同的系统库来重建双方？如果是这样，你很好。如果没有，请仔细检查编译器和系统库的文档（不要屏住呼吸）
【讨论】：