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

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

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

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

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.

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

在这种情况下，结果在大多数实现中都是相同的，这是偶然的;求值的顺序仍未确定。考虑f(i = -1, i = -2):这里，顺序很重要。在你的例子中，这无关紧要的唯一原因是两个值都是-1。

假定表达式被指定为具有未定义行为的表达式，恶意兼容的编译器可能在计算f(i = -1, i = -1)并中止执行时显示不适当的映像，但仍然被认为是完全正确的。幸运的是，据我所知，没有编译器这样做。

赋值操作符可以重载，在这种情况下，顺序可能很重要:

struct A {
    bool first;
    A () : first (false) {
    }
    const A & operator = (int i) {
        first = !first;
        return * this;
    }
};

void f (A a1, A a2) {
    // ...
}


// ...
A i;
f (i = -1, i = -1);   // the argument evaluated first has ax.first == true