问我可以在用于C++14客户端应用程序的库中使用C++11吗？

EN

如果我正在构建一个库，假定库的某些“客户端”可能只使用C++11，那么我可以使用C++14来编译库本身吗？

是的，一般来说，这应该是可能的。

我正是这样做的GCC的文件系统TS的实现。<experimental/filesystem>头是用纯C++11编写的，可以由C++11客户端包含，但是libstdc++fs.a中的实现是用C++14编写的。

与C++11相比，是否存在API/ABI/link兼容性问题？

C++11和C++14之间没有任何需要实现破坏其链接时间兼容性的更改。这并不意味着实现不会破坏它，但它们并不是必需的。

对于GCC来说，我相信C++11和C++14完全兼容API和ABI，除了下面提到的constexpr和大小分配问题之外。

只要我避免公共API中的某些新特性，用C++14实现和构建库安全吗?如果是的话，我必须避免什么？

这取决于您的编译器，但理论上是可能的。

显然，要避免在C++14中无效的任何C++11语言特性(例如函数返回类型推断、带有auto参数的泛型lambdas或变量模板)和任何C++14库实体，如std::make_unique、std::integer_sequence, orstd::shared_timed_mutex`。

C++14中几乎所有更改的列表都可以在SD-6中找到。

需要注意的一点是，非静态constexpr成员函数的含义在C++11和C++14之间发生了变化。

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。