我想了解以下代码的使用
int result = 0;
int factor = 1;
for (...) {
result = ...
factor *= 10;
}
return result;
n次，则factor将被乘以10，恰好n次。然而，在被乘以10的总计n-1次后，factor只会被使用一次。如果我们假设factor除了在循环的最后一次迭代时可能溢出外，永远不会溢出，那么这样的代码是否可以接受？在这种情况下，factor的值在溢出发生后显然不会再被使用。
我正在就是否应该接受这样的代码进行辩论。可以将乘法放在if语句中，并且在可以溢出的最后一次循环迭代中不执行乘法。缺点是它会使代码混乱，并增加一个不必要的分支，需要在所有先前的循环迭代中进行检查。我也可以少迭代一次循环，并在循环之后再复制一次循环体，但这样会使代码变得更加复杂。
实际问题中的代码用于紧密的内部循环，占用了实时图形应用程序总CPU时间的大部分。
编译器假设一个有效的 C++ 程序不包含未定义行为。例如：
if (x == nullptr) {
*x = 3;
} else {
*x = 5;
}
如果x == nullptr，则对其进行解引用并分配值是未定义行为。因此，这个程序能够正常运行的唯一方法是当x == nullptr永远不会为真，并且编译器可以根据仿佛是规则推断出，上述代码等效于：
*x = 5;
现在在您的代码中
int result = 0;
int factor = 1;
for (...) { // Loop until factor overflows but not more
result = ...
factor *= 10;
}
return result;
// nothing :(
INT_MAX >= 10000000000 上调用，则这甚至可能是一种“有用的优化”，在 INT_MAX 较小的情况下，可以调用不同的函数。 - R.. GitHub STOP HELPING ICEi <= n循环总是非无限的，就像i<n循环一样。并且在循环中将int i提升为指针宽度，而不必重新进行符号处理以可能包含前4G个数组元素。 - Peter Cordesint溢出的行为是未定义的。
如果在循环体外读取factor，则不重要；如果它已经溢出，那么你的代码在溢出后，甚至更令人矛盾地说，在溢出之前的行为是未定义的。
保留这个代码可能会引起一个问题，编译器在优化方面变得越来越激进。特别是它们正在养成一种习惯，即假设未定义的行为从不发生。为了实现这一点，它们可能会完全删除for循环。
你不能用unsigned类型来代替factor吗？不过这样做,就需要担心包含两者的表达式中int转换为unsigned的非预期转换
factor被用在赋值给自身的操作中。 - Bathsheba考虑现实世界的优化器可能会很有见地。循环展开是一种已知的技术。循环展开的基本思想是：
for (int i = 0; i != 3; ++i)
foo()
可能更好地在幕后实现为
foo()
foo()
foo()
这是一个简单的情况，具有固定的边界。但是现代编译器也可以为变量边界执行此操作：
for (int i = 0; i != N; ++i)
foo();
成为
__RELATIVE_JUMP(3-N)
foo();
foo();
foo();
显然，仅当编译器知道N≤3时，此方法才有效。这就回到了最初的问题：
int result = 0;
int factor = 1;
for (...) {
result = ...
factor *= 10;
}
return result;
编译器知道有符号数不会溢出，因此它知道在32位架构上循环最多可以执行9次。10^10 > 2^32。因此，它可以对循环进行9次展开。但是预期的最大迭代次数是10次！.
可能的情况是，你会得到一个相对于汇编指令(9-N)的跳转，其中N==10，所以偏移量为-1，这个跳转指令本身。哎呀。这是一个完全有效的循环优化方法，适用于定义明确的C++，但是给出的例子却成了一个紧凑的无限循环。
任何有符号整数溢出都会导致未定义行为，无论是否读取了溢出值。
也许在您的用例中，您可以将第一次迭代从循环中提取出来，将其转换为：
int result = 0;
int factor = 1;
for (int n = 0; n < 10; ++n) {
result += n + factor;
factor *= 10;
}
// factor "is" 10^10 > INT_MAX, UB
变成这样
int factor = 1;
int result = 0 + factor; // first iteration
for (int n = 1; n < 10; ++n) {
factor *= 10;
result += n + factor;
}
// factor is 10^9 < INT_MAX
启用优化后，编译器可能会将上述第二个循环展开为一个条件跳转。
factor *= 10;。 - Peter Cordesfor(... i <= n ...)循环不是无限循环，即使n是未知的。它还允许它们将int循环计数器提升为指针宽度，而不是重新进行符号扩展。（因此，在这种情况下，UB的后果可能是访问数组的低64k或4G元素之外，如果您期望对i进行符号包装，则可能会出现这种情况。）ud2的非法指令。(请注意，函数可能永远不会被调用，因此编译器通常不会失控并破坏其他函数，甚至是不触发未定义行为的函数可能路径。也就是说，它编译成的机器码必须对所有不导致UB的输入都有效。)
最有效的解决方案可能是手动剥离最后一次迭代，以避免不必要的factor *= 10。
int result = 0;
int factor = 1;
for (... i < n-1) { // stop 1 iteration early
result = ...
factor *= 10;
}
result = ... // another copy of the loop body, using the last factor
// factor *= 10; // and optimize away this dead operation.
return result;
factor。然后，您可以让无符号乘法溢出，并且它将执行定义良好的包装到2的某个幂（无符号类型中的值位数）。int x = u; 之后，gcc 和 clang 不会优化掉 x>=0，即使没有 -fwrapv，因为它们定义了行为。int factor = 1;
for (int j = 0; j < n; ++j) {
...
factor *= 10;
}
你可以书写：
int factor = 0;
for (...) {
factor = 10 * factor + !factor;
...
}
!factor 不会引入分支。 xor ebx, ebx
L1:
xor eax, eax
test ebx, ebx
lea edx, [rbx+rbx*4]
sete al
add ebp, 1
lea ebx, [rax+rdx*2]
mov edi, ebx
call consume(int)
cmp r12d, ebp
jne .L1
int factor = 0;
for (...) {
factor = factor ? 10 * factor : 1;
...
}
优化后也会产生无分支汇编:
mov ebx, 1
jmp .L1
.L2:
lea ebx, [rbx+rbx*4]
add ebx, ebx
.L1:
mov edi, ebx
add ebp, 1
call consume(int)
cmp r12d, ebp
jne .L2
(使用GCC 8.3.0 -O3编译)
f* = 10和f * 5 * 2操作效率几乎相同，并且第一个“LEA”隐藏了“test”的延迟。但是它确实在循环内部花费了额外的uops，因此可能会降低吞吐量（或至少存在超线程友好性问题）。 - Peter Cordesfor语句圆括号里的内容，但我假设是这样的：for (int n = 0; n < 10; ++n) {
result = ...
factor *= 10;
}
你可以将计数器的增加和循环终止条件检查放入循环体内部：
for (int n = 0; ; ) {
result = ...
if (++n >= 10) break;
factor *= 10;
}
循环中的汇编指令数量将保持不变。
受安德烈·亚历山德鲁斯库的演讲“速度在人们的头脑中找到”的启发。
考虑以下函数：
unsigned mul_mod_65536(unsigned short a, unsigned short b)
{
return (a*b) & 0xFFFFu;
}
未定义行为有许多不同的表现形式，可接受的取决于用途。
在实时图形应用程序中消耗大量CPU时间的紧密内部循环
这本身就有点不寻常，但即使如此...如果确实是这种情况，那么UB最可能存在于“允许、可接受”的领域。图形编程以其黑科技和丑陋的代码而闻名。只要“它有效”且生成一个帧不超过16.6ms，通常没人在意。但是，请注意调用UB的含义。
首先，有标准。从那个角度来看，没有什么可讨论的，也没有任何理由来证明你的代码是有效的。没有任何条件或时间限制，它只是无效的代码。你也许可以说这是你的中指，95-99%的时间你都会顺利过关。
下面是硬件方面。在一些不常见、奇怪的架构中，这是一个问题。我之所以说“不常见、奇怪”，是因为在占据所有计算机80%的一种架构（或者占据所有计算机95%的两种架构）上，溢出在硬件层面上是一个“是的，无论如何都不用管”的事情。你肯定会得到一个垃圾（尽管仍然可预测）的结果，但没有邪恶的事情发生。x+1 肯定比 x 大，编译器/优化器可以利用这个知识。现在，对于先前提到的情况，编译器确实已知会采取这种方式，并简单地剥离完整的代码块（几年前存在一个基于编译器由于这个原因而死亡剥夺了一些验证代码的 Linux 漏洞）。int result = 0;
int factor = 10;
for (...) {
factor *= 10;
result = ...
}
return result;
... 循环体，其 factor = 1 或 factor = 10 的值，只有100及以上的才会执行。如果您想让它正常工作，您必须剥离第一次迭代，并且仍要从 factor = 1 开始。 - Peter Cordes