C++17编译的静态库是否可在C++14标准的项目中使用？

该方案默认情况下无法正常实现，具体原因和可行调整方案如下：

核心障碍1：头文件编译阶段直接报错 #

项目B采用C++14标准编译时，第一步就会解析项目A的公开头文件：

• 如果头文件中包含C17专属语法，比如inline修饰命名空间作用域的内联变量、if constexpr、折叠表达式等，C14编译器会直接报语法错误
• 如果头文件中引用了C17新增的标准库类型，比如std::optional、std::any、std::variant等，C14的标准库中没有对应定义，会直接报类型未找到错误
  只要头文件存在C++17专属特性，项目B连编译阶段都无法通过，和后续的静态库链接没有关系。

调整后可运行的前提条件 #

如果能将项目A的公开头文件完全改造为C++14兼容格式，仅在A的内部实现（.cpp文件、不对外暴露的内部头文件）中使用C++17特性，存在可正常运行的可能，需要满足以下要求：

• 对外接口完全删除C17特性：比如用「返回静态变量引用的静态函数」替代对外暴露的C17内联变量，用自定义的可选类型或者指针参数替代std::optional作为参数/返回值
• 保证编译器ABI兼容：C标准本身不保证不同标准版本编译的代码ABI兼容，需要确认你使用的编译器（GCC/Clang/VS等）同版本下C17和C++14的ABI一致，同时两个项目的其他编译选项（对齐规则、异常开关、运行库版本、RTTI开关等）完全一致
• 禁止跨模块传递标准库类型：不要在项目A的接口中返回或者传递标准库类型，不同C++版本的标准库内部实现可能存在差异，直接使用会触发未定义行为

最稳妥的落地建议 #

推荐给项目A封装一层纯C兼容的对外接口，公开头文件完全用C语法编写，内部实现仍然可以自由使用C17特性。编译为静态库后，项目B不管是C14还是其他C++版本都可以直接调用，完全规避语法和ABI兼容问题。

内容的提问来源于stack exchange，提问作者Anil Can