实际上，不依赖于编译器会检查i是否被赋值两次的事实是有原因的，这样就可以用一次赋值替换它。如果我们有一些表达呢?

void g(int a, int b, int c, int n) {
    int i;
    // hey, compiler has to prove Fermat's theorem now!
    f(i = 1, i = (ipow(a, n) + ipow(b, n) == ipow(c, n)));
}

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

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

实际上，不依赖于编译器会检查i是否被赋值两次的事实是有原因的，这样就可以用一次赋值替换它。如果我们有一些表达呢?

void g(int a, int b, int c, int n) {
    int i;
    // hey, compiler has to prove Fermat's theorem now!
    f(i = 1, i = (ipow(a, n) + ipow(b, n) == ipow(c, n)));
}

令人困惑的是，将一个常量值存储到一个局部变量中并不是C设计用于运行的每个架构上的一个原子指令。在这种情况下，运行代码的处理器比编译器更重要。例如，在ARM上，每条指令都不能携带一个完整的32位常量，在一个变量中存储一个int就需要更多的指令。这个伪代码的例子，你一次只能存储8位，并且必须在32位寄存器中工作，i是一个int32:

reg = 0xFF; // first instruction
reg |= 0xFF00; // second
reg |= 0xFF0000; // third
reg |= 0xFF000000; // fourth
i = reg; // last

你可以想象，如果编译器想要优化它，它可能会将相同的序列交叉两次，你不知道什么值会被写入i;假设他不太聪明

reg = 0xFF;
reg |= 0xFF00;
reg |= 0xFF0000;
reg = 0xFF;
reg |= 0xFF000000;
i = reg; // writes 0xFF0000FF == -16776961
reg |= 0xFF00;
reg |= 0xFF0000;
reg |= 0xFF000000;
i = reg; // writes 0xFFFFFFFF == -1

然而，在我的测试中，gcc足够友好，可以识别相同的值被使用了两次，并生成它一次，没有任何奇怪的事情。得到-1和-1 但我的例子仍然是有效的，因为重要的是要考虑到即使是常数也可能不像它看起来那么明显。

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

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

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

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

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.