C++17 Polyfills与Boost：旧标准下可移植代码规范咨询

不少ISO C++的新特性最初都脱胎于Boost库，这自然给编写可移植代码带来了不少需要明确的规范问题。下面针对几个核心疑问给出我的实操建议：

核心技术问题解答 #

• 在旧版C++标准下，有没有可移植使用新特性的标准方式？
  其实没有所谓的“标准方式”，但行业里常用垫片（shim）/兼容层方案：通过宏判断编译器和标准版本，在支持新特性的环境下直接用std实现，不支持的环境就用Boost或自定义兼容版本。举个例子，想用variant可以这么写：

  #if __cplusplus >= 201703L
  #include <variant>
  using MyVariant = std::variant<int, std::string>;
  #else
  #include <boost/variant.hpp>
  using MyVariant = boost::variant<int, std::string>;
  #endif
  

  这种方式能最大化保证可移植性，但要注意不同实现的细微差异——比如部分Boost特性和标准版本的行为可能不完全一致，需要仔细测试验证。

• 已经在用Boost了，该继续用Boost版本、C++17版本还是实验版本？
  得结合你的项目场景判断：

  • 如果需要兼容旧编译器/旧标准，继续用Boost版本更稳妥，毕竟Boost对老环境的支持做得非常成熟；
  • 如果项目已全面切换到C++17及以上，且无需兼容老环境，优先用std版本——标准库的维护是长期稳定的，和语言本身的整合度也更好；
  • 实验版本（比如编译器的std::experimental）别在生产代码里碰，除非你能接受功能随时被移除或修改的风险，它只适合测试环境尝鲜。
    要是担心切换成本，可以逐步过渡：保留现有Boost代码，新功能优先用标准版本，等时机成熟再全面迁移。

• 可移植性的追求该把握什么尺度？
  没有绝对的“完美可移植”，要平衡开发成本、维护成本和目标环境：

  • 如果项目要覆盖从C03到C20的各类环境，那确实要做大量兼容工作；但如果目标只是主流编译器的最新几个版本，完全没必要过度兼容；
  • 优先保证核心功能在目标环境的可移植性，非核心辅助功能可以针对性优化；
  • 别为了兼容极端老旧环境牺牲代码可读性和性能，现在主流编译器对新标准的支持已经相当完善了。

零散的单一特性问题参考 #

目前这类全局性问题在常见FAQ、C++核心指南、Boost FAQ或ISO文档里都找不到统一答案，只能看到一些针对单一特性的零散讨论，比如：

• C++11特性的垫片实现方案
• boost::variant和std::variant别名无法编译的问题
• 如何正确地给std补充缺失的功能

内容的提问来源于stack exchange，提问作者Bruce Adams