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

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

首先，“标量对象”意味着像int、float或指针这样的类型(参见c++中的标量对象是什么?)

其次，似乎更明显的是

f(++i, ++i);

会有未定义的行为。但

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

不太明显。

一个稍微不同的例子:

int i;
f(i = 1, i = -1);
std::cout << i << "\n";

最后发生了什么赋值，i = 1，还是i = -1?标准中没有定义。实际上，这意味着i可能是5(请参阅harmic的答案，以获得完全合理的解释)。或者您的程序可以段错误。或者重新格式化你的硬盘。

但现在你会问:“那我的例子呢?两次赋值都使用相同的值(-1)。还有什么不清楚的呢?”

你说得对……除了c++标准委员会描述的方式。

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

他们本可以为你的特殊情况破例，但他们没有。(他们为什么要这么做呢?那又有什么用呢?)所以i仍然可以是5。或者你的硬盘可能是空的。因此，你问题的答案是:

它是未定义的行为，因为它没有定义行为是什么。

(这一点值得强调，因为许多程序员认为“未定义”意味着“随机”或“不可预测”。它不;它意味着不是由标准定义的。行为可能是100%一致的，但仍然没有定义。)

它可以被定义为行为吗?是的。它被定义了吗?不。因此，它是“未定义的”。

也就是说，“未定义”并不意味着编译器会格式化你的硬盘…这意味着它可以并且仍然是一个标准兼容的编译器。实际上，我确信g++、Clang和MSVC都能达到您的预期。他们只是“不必”。

另一个不同的问题可能是，为什么c++标准委员会选择不对这种副作用进行排序?这个答案将涉及历史和委员会的意见。或者在c++中没有对副作用进行排序有什么好处?，这就允许任何理由，不管它是否是标准委员会的实际推理。你可以在这里或programmers.stackexchange.com上问这些问题。

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

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

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

// 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的常量表达式是不允许的，这会导致编译失败。因此，改变一个常量可能会在其他地方导致编译错误。恕我直言，这很不幸。但是，将这些事情限制在不可避免的范围内当然是好的。

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

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.

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

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

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

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

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

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