c++ 17定义了更严格的求值规则。特别地，它对函数参数进行排序(尽管没有指定顺序)。

N5659§4.6:15 当A在B之前排序或B在A之前排序时，计算A和B是不确定排序的， 但没有说明是哪一种。[注意:不确定排序的计算不能重叠，但也可以重叠 先执行。-结束注释] N5659§8.2.2:5 的 参数的初始化，包括每个相关的值计算和副作用，都是不确定的 按任何其他参数的顺序排列。

它允许一些情况，之前是UB:

f(i = -1, i = -1); // value of i is -1
f(i = -1, i = -2); // value of i is either -1 or -2, but not specified which one

由于操作是无序的，因此执行赋值的指令不能交叉。这样做可能是最佳的，这取决于CPU架构。参考页面说明如下:

If A is not sequenced before B and B is not sequenced before A, then two possibilities exist: evaluations of A and B are unsequenced: they may be performed in any order and may overlap (within a single thread of execution, the compiler may interleave the CPU instructions that comprise A and B) evaluations of A and B are indeterminately-sequenced: they may be performed in any order but may not overlap: either A will be complete before B, or B will be complete before A. The order may be the opposite the next time the same expression is evaluated.

这本身似乎不会造成问题——假设正在执行的操作是将值-1存储到内存位置。但是，编译器不能将其优化为具有相同效果的单独指令集，但如果该操作与同一内存位置上的另一个操作交织在一起，则可能会失败。

例如，想象一下，与将值-1载入内存相比，先将内存归零，再将其递减更有效。那么这个:

f(i=-1, i=-1)

可能成为:

clear i
clear i
decr i
decr i

现在i是-2。

这可能是一个虚假的例子，但它是可能的。

这只是回答了“我不确定“标量对象”可能意味着什么，除了像int或float这样的东西”。

我会将“标量对象”解释为“标量类型对象”的缩写，或者只是“标量类型变量”。然后，指针，enum(常量)是标量类型。

这是一篇关于标量类型的MSDN文章。

一个不因为两个值相同而从规则中例外的实际原因:

// config.h
#define VALUEA  1

// defaults.h
#define VALUEB  1

// prog.cpp
f(i = VALUEA, i = VALUEB);

考虑一下这种情况是允许的。

现在，几个月后，改变的需求出现了

 #define VALUEB 2

看起来是无害的，不是吗?然而突然prog.cpp就不能再编译了。 但是，我们认为编译不应该依赖于字面量的值。

底线:该规则没有例外，因为它将使成功的编译依赖于常量的值(而不是类型)。

EDIT

@ hearttware指出，在某些语言中，当B为0时，形式为A DIV B的常量表达式是不允许的，这会导致编译失败。因此，改变一个常量可能会在其他地方导致编译错误。恕我直言，这很不幸。但是，将这些事情限制在不可避免的范围内当然是好的。

在我看来，关于函数参数表达式排序的唯一规则是:

3)当调用一个函数时(无论该函数是否内联，以及是否使用显式函数调用语法)，与任何参数表达式或指定被调用函数的后缀表达式相关的每一个值计算和副作用，都在被调用函数体中的每一个表达式或语句执行之前进行排序。

这并没有定义参数表达式之间的排序，所以我们最终会得到这样的结果:

1)如果一个标量对象上的副作用相对于同一标量对象上的另一个副作用是未排序的，则该行为是未定义的。

实际上，在大多数编译器上，您引用的示例都可以正常运行(而不是“擦除您的硬盘”和其他理论上未定义的行为结果)。 然而，这是一种负担，因为它取决于特定的编译器行为，即使分配的两个值是相同的。此外，很明显，如果你试图分配不同的值，结果将是“真正的”未定义:

void f(int l, int r) {
    return l < -1;
}
auto b = f(i = -1, i = -2);
if (b) {
    formatDisk();
}

行为通常被指定为未定义，如果有一些可以想象的原因，为什么一个试图“有帮助”的编译器可能会做一些完全意想不到的行为。

In the case where a variable is written multiple times with nothing to ensure that the writes happen at distinct times, some kinds of hardware might allow multiple "store" operations to be performed simultaneously to different addresses using a dual-port memory. However, some dual-port memories expressly forbid the scenario where two stores hit the same address simultaneously, regardless of whether or not the values written match. If a compiler for such a machine notices two unsequenced attempts to write the same variable, it might either refuse to compile or ensure that the two writes cannot get scheduled simultaneously. But if one or both of the accesses is via a pointer or reference, the compiler might not always be able to tell whether both writes might hit the same storage location. In that case, it might schedule the writes simultaneously, causing a hardware trap on the access attempt.

当然，有人可能会在这样的平台上实现C编译器，但这并不意味着在硬件平台上使用小到可以被原子处理的类型存储时不应该定义这种行为。试图以无序的方式存储两个不同的值可能会导致奇怪，如果编译器没有意识到它;例如，给定:

uint8_t v;  // Global

void hey(uint8_t *p)
{
  moo(v=5, (*p)=6);
  zoo(v);
  zoo(v);
}

if the compiler in-lines the call to "moo" and can tell it doesn't modify "v", it might store a 5 to v, then store a 6 to *p, then pass 5 to "zoo", and then pass the contents of v to "zoo". If "zoo" doesn't modify "v", there should be no way the two calls should be passed different values, but that could easily happen anyway. On the other hand, in cases where both stores would write the same value, such weirdness could not occur and there would on most platforms be no sensible reason for an implementation to do anything weird. Unfortunately, some compiler writers don't need any excuse for silly behaviors beyond "because the Standard allows it", so even those cases aren't safe.