为什么c ++没有指定用于评估函数争论的顺序？

Question

在我看来，它是任何函数式编程语言的一个非常基本和必要的特性，可以知道函数调用的参数将被计算的顺序。我错了吗？为什么C ++没有定义这个？是否正在讨论任何未来版本的C ++？

Answer 1

  

为什么C ++不这样做？

对于初学者来说，C ++ 不是一种函数式编程语言。

评估参数的最快方法取决于实现和体系结构，因此编译器可以选择。我们不会在C ++中支付我们不使用的内容，因此如果您需要自己指定评估顺序，那么您可以使用命名变量明确地执行此操作。

尽管如此，继续保留新标准的主题，留下神圣的C ++范例C++17 will sadly add some evaluation order guarantees，破坏了所有这些。

Answer 2

从C ++ 17开始，它保证参数将被线性评估，并且不会交错，但不会以任何特定的顺序 - https://channel9.msdn.com/Shows/C9-GoingNative/GoingNative-52-ISO-C-Oulu-Debriefing

之前没有的原因是允许编译器实现者优化评估顺序的范围，结果是不使用或使用不当，逻辑顺序可以并且将被强制执行且影响可以忽略不计

编辑：更正，谢谢@Oktalist

我实际上认为这是一个奇怪的决定，对我来说很明显，交错比参数评估重新排序更容易进行优化，我认为我们不会比以前更加信任地对待参数评估。

Answer 3

C ++不是一种函数式编程语言。事实上，在这种语言中（没有副作用），评估顺序无关紧要。

C ++在编译器的实现方面尽可能多地保留，特别是在可能发生优化机会的情况下。在修复这样的事情之前，咨询现有的编译器编写者以查看是否存在成本。

在C ++ 17中添加了一些评估保证，包括重载运算符和完整参数规则。但仍然是哪个参数首先是未指定的。在C ++ 17中，现在指定赋予调用什么的表达式（函数调用的(左侧的代码）在参数之前，以及哪个参数首先评估是在下一个被启动之前完全评估的，而在对象方法的情况下，在方法的参数之前评估对象的值。 （此描述中可能存在一些小错误：请求一个较窄的问题，以获得更严格的答案）。

对这些进行了审查并确定不会对现有编译器造成重大问题。对于论据的重新排序被考虑并被丢弃，大概是有充分理由的。或者甚至是糟糕的原因，比如现有的编译器都有默认顺序，并且它可能会破坏（可能是不合规的）该编译器上的代码，迫使他们全部按照一个全局顺序执行它。

简而言之，C ++为编译器编写者留下了很多自由。这让编译器编写者可以在奇怪的缝隙中找到优化机会。今天可用的优化方式远远超出C的原始编写者，更不用说C ++，可能怀疑是实用的还是被认为是合理的。