如果我建立一个图书馆，我认为图书馆的某些“客户”可能只使用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使其工作的具体事项。 –