我可以在C++ 11客户端应用程序库中使用C++ 14吗?
如果我建立一个图书馆,我认为图书馆的某些“客户”可能只使用C++ 11,我可以使用C++ 14编译它的内部库吗?是否有API/ABI /链接兼容性问题与C++ 11?只要我避免使用公共API中的某些新特性,是否可以安全地使用C++ 14来实现和构建库,如果是这样,我必须避免什么?或者它在最终的软件项目中混合使用C++ 11和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
和size-deallocation问题。
只要我在公共API中避免某些新特性,是否可以安全地使用C++ 14来实现和构建库,如果是这样,我必须避免什么?
它取决于你的编译器,但理论上它是可能的。
明显地避免任何在C++ 11中无效的C++ 14语言特性(例如函数返回类型推导或带有参数auto
的泛型lambdas或可变模板)以及任何C++ 14库实体,如std::make_unique
,std::integer_sequence, or
std :: shared_timed_mutex`。
C++ 14中几乎所有变化的列表可以在SD-6中找到。
有一点需要注意的是,非静态的constexpr
成员函数的含义在C++ 11和C++ 14之间改变了。在C++ 11中,此成员函数是const
:
struct X {
constexpr int foo();
};
在C++ 14中,它是非常量的。能够同时与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允许您使用-fno-sized-deallocation
编译C++ 14代码以禁用新功能,以便您的C++ 14库代码永远不会调用operator delete
的该版本。
只要客户端使用相同的编译器版本,即使他们不使用C++ 14功能,也可以使其工作。如果他们使用不同版本的编译器,那么在使用Visual Studio时肯定无法工作。 –
你的确切编译器是什么?什么编译器会使用它? – Yakk
OSX上的Clang; Linux上的Clang或gcc; Windows上的MSVS。为了争论,我们假设库和应用程序都使用相同的编译器和相同的版本,所以我的问题归结为我是否可以使用-std = C++ 14作为库,而-std = c + +11在应用程序中,以及我需要记住公共API使其工作的具体事项。 –