如果我正在构建一个库,我假设库中的某些"客户"可能只使用C++ 11,那么我可以使用C++ 14为其内部编译库本身吗？与C++ 11相比,是否存在API/ABI /链接兼容性问题？只要我避免使用公共API中的某些新功能,使用C++ 14实现和构建库是否安全？如果是这样,我必须避免哪些内容？或者在最终软件项目中混合使用C++ 11和C++ 14本质上是不兼容的？
它是一个跨平台的库,BTW,所以我需要在Linux,OSX和Windows上构建它.
如果我正在构建一个库,我假设库中的某些"客户"可能只使用C++ 11,那么我可以使用C++ 14为其内部编译库本身吗？
是的,一般来说应该是可能的.
我这样做是为了GCC实现Filesystem TS.所述<experimental/filesystem>报头是用纯C++ 11,并且可以通过C++ 11级的客户端被包括,但在实施libstdc++fs.a是用C++ 14.
与C++ 11相比,是否存在API/ABI /链接兼容性问题？
C++ 11和C++ 14之间没有任何变化需要实现来破坏它们的链接时兼容性.这并不意味着实现不会破坏它,但它们不是必需的.
对于GCC,我相信C++ 11和C++ 14完全兼容API和ABI,除了constexpr下面提到的大小释放问题.
只要我避免使用公共API中的某些新功能,使用C++ 14实现和构建库是否安全？如果是这样,我必须避免哪些内容？
这取决于你的编译器,但理论上它是可能的.
显然避免任何C++ 14语言功能无效的在C++ 11(如函数返回类型扣,或包含通用的lambda auto参数,或变量模板)和任何C++ 14库的实体,如std::make_unique,std::integer_sequence, orSTD: :shared_timed_mutex`.
在SD-6中可以找到C++ 14中几乎所有变化的列表.
需要注意的一点是,非静态constexpr成员函数的含义在C++ 11和C++ 14之间发生了变化.在C++ 11中,这个成员函数是const:
struct X {
constexpr int foo();
};
在C++ 14中,它是非const的.要与C++ 11和C++ 14兼容,您应该明确地将其限定为const:
struct X {
constexpr int foo() const;
};
这在C++ 11和C++ 14中都是一样的.
另一个需要注意的是,在C++ 11和C++ 14中,这个运算符意味着不同的东西:
void operator delete(void*, std::size_t);
如果C++ 11客户端代码定义了该函数,那么用C++ 14编译的库最终可能会调用它而不是通常的那样operator delete(void*),这可能是错误的.这可能是非常罕见的,并且在实际代码中不是问题,但它是可能的.G ++和Clang允许您编译C++ 14代码-fno-sized-deallocation以禁用新功能,因此您的C++ 14库代码永远不会调用该版本operator delete.