constexpr 允许可以在编译时求值的表达式在编译时求值。
为什么甚至需要这个关键字？为什么不允许或要求编译器在编译时评估所有表达式？
标准库的constexpr应用程序不均衡，这会带来很多不便。将constexpr设置为“默认”将解决该问题，并可能会改善大量现有代码。
注意：尽管有以下情况，我还是同意将constexpr设置为默认值。但是您问为什么还没有完成，所以要回答一下，我将简单介绍一下mattnewport的最后评论：
考虑今天的情况。您试图在需要常量表达式的上下文中使用标准库中的某些函数。它没有标记为constexpr，因此会出现编译器错误。这似乎是愚蠢的，因为要使其正常工作，唯一需要更改的就是在定义中添加constexpr一词。
现在考虑我们采用您的建议的替代宇宙中的生活。您的代码现在可以编译了，是的！明年，您决定将Windows支持添加到您正在从事的任何项目中。它能有多难？您将为Windows用户使用Visual Studio进行编译，并为其他所有人继续使用gcc，对吗？
但是，当您第一次尝试在Windows上进行编译时，会遇到很多编译器错误：该函数不能在常量表达式上下文中使用。您查看有问题的函数的代码，并将其与gcc附带的版本进行比较。事实证明，它们稍有不同，并且gcc附带的版本完全出于偶然而满足constexpr的技术要求，同样，Visual Studio附带的版本出于偶然性而又不满足那些要求。怎么办？
没问题，我将向Microsoft提交错误报告：此功能应该已修复。他们关闭了您的错误报告：标准从不说该函数必须在常量表达式中可用，因此我们可以根据需要实现。因此，您向gcc维护者提交了错误报告：为什么不警告我我在使用不可移植的代码？他们也关闭了它：我们应该怎么知道它不是便携式的？我们无法跟踪其他人如何实现标准库。
怎么办？没有人真正做错任何事情。不是您，不是gcc的人，也不是Visual Studio的人。但是，您仍然会遇到无法移植的代码，并且在这一点上还不是一个快乐的露营者。在所有其他条件相同的情况下，良好的语言标准将尝试使这种情况尽可能少发生。
即使我使用了不同编译器的示例，当您尝试升级到同一编译器的较新版本，甚至尝试使用不同的设置进行编译时，也可能会发生这种情况。例如：该函数包含一个assert语句，以确保使用有效的参数对其进行调用。如果在禁用断言的情况下进行编译，则断言“消失”并且该函数符合constexpr的规则；如果启用断言，那么它将不符合它们。（现在，由于constexpr的规则非常宽泛，这在今天变得不太可能了，但是在C ++ 11规则下这是一个更大的问题。但是原则上讲，这一点直到今天仍然存在。）
最后，我们来看看公认的次要错误消息。在当今世界，如果我尝试cout在constexpr函数中的语句中做一些事情，我马上就会收到一个很好的简单错误。在您的世界中，我们将拥有与模板相同的情况，从深层堆栈跟踪一直到输出流实现的最底层。不是致命的，但肯定令人讨厌。
这已经迟了一年半了，但是我仍然希望它能有所帮助。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句