是否有理由不使用最新的C++标准？

我看到IDE中的默认标准通常不是最新发布的标准，甚至不是IDE中的最新标准。 例如，JetBrains的Clion有C++20和C++17，但默认选项是C++14

---

是否有理由不使用最新发布的标准？

作为一般规则，如果可以，请使用最新的标准

但是，在某些情况下，您可能会选择使用旧版本，这有一些原因

您的代码使用的特性改变了新标准中的行为，或者被彻底删除。如果您没有时间更新代码，那么为旧标准编译是合理的

您的工具链可能无法正确实施新标准。可能会有已知的bug迫使你坚持使用旧的bug

您需要在多个平台上支持多个编译器，但并非所有的组合都支持新标准

您需要与旧编译器为旧标准构建的代码保持二进制兼容，并且您没有重新编译代码的源代码。在这种情况下，您可能被迫使用相同的旧编译器和语言标准来确保ABI兼容性

公司内部政治可能出于武断的原因强制要求特定版本

认证要求可能要求使用特定的编译器和语言版本。在高度管制的行业，如医疗行业，经常发生这种情况

您的团队对新功能的熟悉程度可能较低，因此使用它们可能会增加出现bug的风险

---

等等，我在现实生活中见过上述所有情况。顺便说一句，如果您的编译器支持C++17或C++20，您可以使用它。有些编译器仅部分支持C++17和C++20，因此默认为C++14。不使用最新标准可能有各种原因。新特性的测试较少，并且与之相关的bug出现的可能性更高。用于检测bug的静态分析器在新版本中可能不如在旧版本中工作得好。开发人员不知道新的特性，所以bug的可能会更高，……使用编译器来编译C++代码。选择能够驱动最新GCC的IDE。关于C++，请参见。阅读编译器、IDE、C++变体的文档，您的Link可以实现一个目标，即编写可移植的C++代码，它可以在任何地方工作，或者尽可能地靠近任何地方，然后使用最新C++标准的特性可能会成为问题。因为现在您的代码不会在不支持最新C++标准的平台上编译。如果您在使用最新C++标准的构建环境中进行开发和测试，那么您可能不知道您马上就有问题，而只有当您在旧平台上实际编译代码时才知道。到那时你可能有很多代码需要重写。认证要求并不要求编译器/语言版本。它们确实需要文档化的验证，以确保代码在构建时能够产生所需的效果。对于高关键性代码，包括验证（例如通过检查机器代码）编译器的输出是否符合原始代码的要求。对一个版本的编译器或其他工具链组件的验证不会自动对任何其他版本进行验证。当更新到新的编译器时，重新验证和文档编制的成本可能会很大。请注意，尽管用户可能会选择标准，即使是最新的标准，而不是旧的标准，因此提供的大多数原因与编译器的默认选择无关。评论中的理由似乎更准确。