c++17 polyfills 和 boost

Question

添加到最近的 ISO C++ 标准中的一些新功能最初是 boost 的一部分。 这自然提出了编写可移植代码的准则问题。

在使用旧版标准时，是否有一种规范的方法可以便携地使用新的语言功能？

如果您已经在使用 boost，您应该继续使用 boost 版本还是 C++17 中的版本还是实验版本？

在便携方面你应该走多远？

我很惊讶没有在某处发现这个问题作为常见问题解答。 核心指南、boost 常见问题解答和/或作为 ISO 委员会文件中不应该有关于此的内容吗？

似乎存在关于个别功能的问题，但考虑到更广泛的观点则较少。 例如：

• C++11 Polyfills
• Aliasing boost::variant or std::variant not compilable
• How to correctly shim functionality into std?

Answer 1

有几个项目提供了 polyfill。 Boost 不是唯一的选择，尽管它可能是最常见和最全面的。 还有其他的，例如：

• https://github.com/tcbrindle/cpp17_headers
• https://www.reddit.com/r/cpp/comments/5oz3zj/c_shims_library/
• https://abseil.io/about/philosophy

您可以使用 using 子句导入适当的版本，但这有风险，因为它掩盖了语义差异 另见：

From boost to std::experimental and furthermore c++17

您可以考虑使用feature test macros 并创建像“cxx17/optional.hpp”这样的标题，其中包含：

#ifdef __cpp_lib_experimental_optional
#include <experimental/optional>
namespace cxx17
{
using std::experimental::optional;
}
#elif __cpp_lib_optional
#include <optional>
namespace cxx17
{
using std::optional;
}
#else
#include <boost/optional.hpp>
namespace cxx17
{
using boost::optional;
}
#endif

但是，这仍然涉及语义差异。 在某些情况下，boost 库会故意与标准有所不同。

您还必须考虑不存在可移植代码之类的东西 只有已移植的代码。你不能保证你的代码会工作 除非您在每个环境中都对其进行了实际测试。

如果您尝试像这样使您的代码可移植并且无意 在那些环境中运行它只是一个 YAGNI（你不会需要它）。 使用功能测试宏表明您很聪明，但如果不使用它们可能会被视为噪音。

如果您已经在使用 boost，假设您可以继续使用它似乎是安全的 并将其留给 boost（和 boost 维护者）来检测您使用的是 C++17 还是 TS 并据此行事。除非你有很多资源，否则你可以假设 boost 库比您的代码更具可移植性。

记录意图是一件好事。 如果你只是想让未来的维护者生活更轻松，但你被困在使用 C++11 现在你可能会考虑做（在 cxx17/import_optional.hpp 中）：

#include <boost/optional.hpp>
namespace cxx17
{
using boost::optional;
}

并使用 cxx17 命名空间表明您希望使用 C++17 但还不能。这也意味着您认为 boost 和 ISO 标准之间的偏差是一个错误 为您的项目。其他用户可能更喜欢增强版。 （例如What are the differences between std::variant and boost::variant?）

这主要适用于纯库扩展。 对于语言本身的更改，您有时可以使用宏来模拟它们。这可能很难看，所以最好坚持给定的标准。

这可能应该是一个社区 wiki，但我会等待，以防更博学的大师提出更好的答案。