主项目用C++11编译，引入C++17库报错，求兼容解决方案

1. 隔离库的C++17接口（推荐） #

核心思路是不让主项目的C11编译单元直接接触C17特性，修改mylib的代码结构：

• 使用Pimpl手法：将包含std::optional的实现细节放到.cpp文件中，头文件仅对外暴露C++11兼容的接口。比如在mylib.h中只声明类的前向声明，用指针封装内部实现。
• 替换接口类型：把std::optional<T>相关接口改为C++11支持的类型，比如返回T*（空指针表示无值），或者引入Boost库使用boost::optional（若项目允许）。

示例修改后的mylib.h：

// 仅暴露C++11兼容接口
class MyLibImpl; // 前向声明
class MyLib {
private:
    MyLibImpl* impl; // 封装实现细节
public:
    MyLib();
    ~MyLib();
    // 用指针替代std::optional<T>
    T* getValue();
};

mylib.cpp中再实现包含std::optional的逻辑，主项目编译时只会识别C++11兼容的头文件，不会触发错误。

2. 单独提升主项目编译单元的标准 #

针对主项目中包含mylib.h的main.cpp，单独设置C17编译标准，其余文件保持C11：
修改主项目的CMakeLists.txt：

...
cmake_minimum_required(VERSION 2.8.12 FATAL_ERROR)
set(CMAKE_CXX_STANDARD 11)
add_subdirectory(mylib)
add_executable(myapp main.cpp)
# 仅让main.cpp使用C++17标准
set_source_files_properties(main.cpp PROPERTIES CXX_STANDARD 17)
target_link_libraries(myapp mylib)
...

也可以用更现代的CMake语法：

target_compile_features(myapp PRIVATE cxx_std_17)

这种方案无需修改库代码，仅调整CMake配置即可，只要main.cpp本身未使用C++11不支持的特性就不会有问题。

3. 引入C++17特性的兼容层 #

给主项目添加第三方兼容库，在C++11环境下提供std::optional的实现：

• 使用独立的optional实现（比如从C17标准库中提取的头文件），或者引入GSL（Guidelines Support Library），它提供的gsl::optional可在C11中使用。
• 注意需在主项目中定义对应编译器宏（如Clang下的_LIBCPP_ENABLE_CXX17_REMOVED_FEATURES），确保编译器识别兼容层的std::optional。不过这种方案会引入额外依赖，存在兼容性风险，仅作为备选。

4. 优化CMake的标准配置方式 #

子库mylib的CMakeLists.txt中，避免使用全局的set(CMAKE_CXX_STANDARD 17)，改用目标级别的编译特性设置，确保库的编译标准不被主项目覆盖：
修改mylib的CMakeLists.txt：

...
add_library(mylib mylib.h mylib.cpp)
# 仅让mylib自身使用C++17特性
target_compile_features(mylib PRIVATE cxx_std_17)
...

再结合方案2为主项目的main.cpp单独设置C++17标准，这种配置更精确，符合CMake的最佳实践。

内容的提问来源于stack exchange，提问作者Nhan Ly-Trong