在项目中仅具有C ++ 17兼容性是否安全？

Question

我正在从头开始一个C++项目。仅支持C++17是否安全？换句话说，是否建议以C++17方式实现的任何功能都具有与C++11或C++14兼容的相应功能？

Answer 1

这是基于观点的概念，但我认为对此有一个客观的看法。

作为一般规则，我会说服Ockham的Razor，无论出于何种原因而拥有相同功能的不同版本都是很糟糕的。除非必须，否则不要介绍它。比复制还差。

设置为标准并准备将来使用-一旦目标构建基础结构支持这些新功能，就可以使用它们，以便最终可以弃用并删除过时的版本。在3到6年内有一个很好的概念，因此您可以围绕它设计界面。

有时可能会提供向后标准兼容性，但并非总是如此，而且可能很麻烦。假设您开始使用某个版本并降级是一个非常冒险的想法。

您不能说使用c ++ 17并提供向后兼容性，因为不可能完全做到并保持相同的接口。

Answer 2

哪种软件？

例如，在库或Linux发行版中的应用程序中，您必须与用户打交道，并且其中一些用户可能仍将在较旧的OS和编译器上，并且不想更新。对于库，如果您想在支持旧功能的同时在API中提供一些新功能，则可能需要宏/编译选项后面的某些功能（例如，std::string_view受支持，否则const std::string &）。对于应用程序ID，请坚持要求的最低版本。

但是，对于您分发的应用程序，可以使用所需的任何版本并捆绑依赖项。因此，您可以使用比系统随附的更新版本的编译器，重建boost C ++等，只需确保您静态链接或捆绑任何DLL /即可。