我在某些语言中知道以下内容:
a += b
比以下更有效:
a = a + b
因为它不需要创建临时变量。这是C的情况吗?使用+ =(以及-=
*=
等)
答案 0 :(得分:36)
所以这是一个明确的答案......
$ cat junk1.c
#include <stdio.h>
int main()
{
long a, s = 0;
for (a = 0; a < 1000000000; a++)
{
s = s + a * a;
}
printf("Final sum: %ld\n", s);
}
michael@isolde:~/junk$ cat junk2.c
#include <stdio.h>
int main()
{
long a, s = 0;
for (a = 0; a < 1000000000; a++)
{
s += a * a;
}
printf("Final sum: %ld\n", s);
}
michael@isolde:~/junk$ for a in *.c ; do gcc -O3 -o ${a%.c} $a ; done
michael@isolde:~/junk$ time ./junk1
Final sum: 3338615082255021824
real 0m2.188s
user 0m2.120s
sys 0m0.000s
michael@isolde:~/junk$ time ./junk2
Final sum: 3338615082255021824
real 0m2.179s
user 0m2.120s
sys 0m0.000s
... 我的计算机和我的编译器在我的操作系统上运行。您的结果可能会也可能不会发生变化但是,在我的系统上,时间是相同的:用户时间2.120秒。
现在只是为了向您展示现代编译器的令人印象深刻,您会注意到我在赋值中使用了表达式a * a
。这是因为这个小问题:
$ cat junk.c
#include <stdio.h>
int main()
{
long a, s = 0;
for (a = 0; a < 1000000000; a++)
{
s = s + a;
}
printf("Final sum: %ld\n", s);
}
michael@isolde:~/junk$ gcc -O3 -S junk.c
michael@isolde:~/junk$ cat junk.s
.file "junk.c"
.section .rodata.str1.1,"aMS",@progbits,1
.LC0:
.string "Final sum: %ld\n"
.text
.p2align 4,,15
.globl main
.type main, @function
main:
.LFB22:
.cfi_startproc
movabsq $499999999500000000, %rdx
movl $.LC0, %esi
movl $1, %edi
xorl %eax, %eax
jmp __printf_chk
.cfi_endproc
.LFE22:
.size main, .-main
.ident "GCC: (Ubuntu 4.4.3-4ubuntu5) 4.4.3"
.section .note.GNU-stack,"",@progbits
编译器找出了我的循环,并将其展开到计算累积和的位置,并将其作为一个常量嵌入到它打印输出中,完全跳过任何类型的循环结构。面对聪明的优化者,你真的认为你会在区分s = s + a
和s += a
方面找到任何有意义的优势吗?!
答案 1 :(得分:22)
这是一个特定于编译器的问题,但我希望所有现代编译器都会给出相同的结果。使用Visual Studio 2008:
int main() {
int a = 10;
int b = 30;
a = a + b;
int c = 10;
int d = 50;
c += d;
}
a = a + b行有反汇编
0014139C mov eax,dword ptr [a]
0014139F add eax,dword ptr [b]
001413A2 mov dword ptr [a],eax
c + = d行有反汇编
001413B3 mov eax,dword ptr [c]
001413B6 add eax,dword ptr [d]
001413B9 mov dword ptr [c],eax
哪个是一样的。它们被编译成相同的代码。
答案 2 :(得分:17)
这取决于a
是什么。
a += b
等同于a = a + b
,除了从抽象的角度来看a
在前一种变体中仅被评估一次。如果a
是一个“纯”值,即如果评估它一次与评估它多次对程序行为没有影响,那么a += b
在所有方面都严格等同于a = a + b
,包括效率。
换句话说,在a += b
和a = a + b
之间实际可以自由选择的情况下(意味着你知道他们做同样的事情),他们通常会有完全相同的效率。当a
代表函数调用时,某些编译器可能会遇到困难(例如,可能不是您的意思),但当a
是非易失性变量时,为两个表达式生成的机器代码将是同样的。
另一个例子,如果a
是一个易变变量,那么a += b
和a = a + b
会有不同的行为,因此效率会有所不同。但是,由于它们不相同,所以在这种情况下,您的问题根本不适用。
答案 3 :(得分:6)
在问题中显示的简单案例中,没有显着差异。赋值运算符分数是指具有如下表达式的表达式:
s[i]->m[j1].k = s[i]->m[jl].k + 23; // Was that a typo?
VS
s[i]->m[j1].k += 23;
两个好处 - 而且我不打算减少打字。毫无疑问,当第一和第二种表达方式不同时是否存在拼写错误;并且编译器不会两次计算复杂表达式。这些天有可能不会产生太大的变化(优化编译器比以前好很多),但你可能还有更复杂的表达式(评估另一个翻译单元中定义的函数,例如,作为其中一部分)下标)编译器可能无法避免两次评估表达式:
s[i]->m[somefunc(j1)].k = s[i]->m[somefunc(j1)].k + 23;
s[i]->m[somefunc(j1)].k += 23;
另外,你可以写(如果你很勇敢):
s[i++]->m[j1++].k += 23;
但你不能写:
s[i++]->m[j1++].k = s[i]->m[j1].k + 23;
s[i]->m[j1].k = s[i++]->m[j1++].k + 23;
(或任何其他排列)因为未定义评估顺序。
答案 4 :(得分:3)
a += b
比
更有效a = a + b
因为前者需要6次击键,而后者需要9次击键。
使用现代硬件,即使编译器是愚蠢的并且使用较慢的代码而不是另一个,在程序的生命周期内节省的总时间可能小于键入三个额外键击的时间
然而,正如其他人所说,编译器几乎肯定产生完全相同的代码,因此前者更有效。
即使您考虑到可读性,大多数C程序员可能会比后者更快地在心理上解析前者,因为它是如此常见的模式。
答案 5 :(得分:2)
几乎在所有情况下,两者都会产生相同的结果。
答案 6 :(得分:2)
除了真正古老或无法编写的编译器之外,只要a
和b
是正常变量就没有区别,因此两者产生相同的结果。
如果您使用的是C ++而不是C,那么运算符重载会允许存在更多实质性差异。