我读了一点关于 拔苗助长因此,Java虚拟机似乎可以选择箍住一些表达式。 我也读到了关于Javascript中函数声明的hoisting。
第一个问题。 谁能确认一下,在C、C++和Java中,是否通常都有hoisting? 还是它们都取决于编译器的优化?
我读了很多C代码的例子,它们总是把变量声明放在顶部,在任何 声称 或 边界条件. 我想这样做会更快一些。声称 和 边界案例 在变量声明之前,考虑到函数可以直接终止。
主要问题。在上下文中,变量声明必须总是在上面吗?(这里是否有葫芦的作用?)还是编译器通过检查这些独立的变量声明来自动优化代码?声称 和 边界案例 首先(在不相关的变量声明之前)?
这里有一个相关的例子。
void MergeSort(struct node** headRef) {
struct node* a;
struct node* b;
if ((*headRef == NULL) || ((*headRef)->next == NULL)) {
return;
}
FrontBackSplit(*headRef, &a, &b);
MergeSort(&a);
MergeSort(&b);
*headRef = SortedMerge(a, b);
}
如上图所示,边界情况并不取决于变量 "a "和 "b"。 因此,将边界情况放在变量声明之上,会使其速度稍快?
更新:
上面的例子没有我希望的那么好,因为变量 "a "和 "b "只是被声明,而不是在那里初始化。 编译器会忽略声明,直到我们真正需要使用它们。
我检查了GNU GCC程序集的变量声明与初始化,这些程序集有不同的执行顺序。编译器没有改变我对独立变量的排序。声称 和 边界案例. 所以,重新排序这些 声称 和 边界案例 做改变装配,从而改变机器的运行方式。
我想这两者之间的差别微乎其微,以至于大多数人从不关心这个问题。
编译器可以按照自己的意愿重新排序修改你的代码,只要修改后的代码与原代码等价,如果按顺序执行即可。所以葫芦是允许的,但不是必须的。这是一种优化,它完全是编译器特有的。
在C++中,变量声明可以随心所欲。在C中,以前它们必须在上下文中顶着,但当c99标准出台后,规则就放宽了,现在它们可以在任何你想在的地方,这和c++类似。不过,很多c程序员还是坚持把它们放在上下文中的顶部。
在你的例子中,编译器可以自由地将if语句移到顶部,但我认为它不会这样做。这些变量只是在堆栈上声明的指针,而且是未初始化的,声明它们的成本是最小的,此外,在函数的开始处创建它们可能比在断言之后创建更有效率。
如果你的声明会涉及到任何副作用,例如
struct node *a = some_function();
那么编译器能重新排序的内容就会受到限制。
编辑。
我用这个小程序检查了GCC的循环提升功能的实际效果
#include <stdio.h>
int main(int argc, char **argv) {
int dummy = 2 * argc;
int i = 1;
while (i<=10 && dummy != 4)
printf("%d\n", i++);
return 0;
}
我用这个命令编译了它:
gcc -std=c99 -pedantic test.c -S -o test.asm
这是输出结果:
.file "test.c"
.def ___main; .scl 2; .type 32; .endef
.section .rdata,"dr"
LC0:
.ascii "%d\12\0"
.text
.globl _main
.def _main; .scl 2; .type 32; .endef
_main:
LFB7:
.cfi_startproc
pushl %ebp
.cfi_def_cfa_offset 8
.cfi_offset 5, -8
movl %esp, %ebp
.cfi_def_cfa_register 5
andl $-16, %esp
subl $32, %esp
call ___main
movl 8(%ebp), %eax
addl %eax, %eax
movl %eax, 24(%esp)
movl $1, 28(%esp)
jmp L2
L4:
movl 28(%esp), %eax
leal 1(%eax), %edx
movl %edx, 28(%esp)
movl %eax, 4(%esp)
movl $LC0, (%esp)
call _printf
L2:
cmpl $10, 28(%esp)
jg L3
cmpl $4, 24(%esp)
jne L4
L3:
movl $0, %eax
leave
.cfi_restore 5
.cfi_def_cfa 4, 4
ret
.cfi_endproc
LFE7:
.ident "GCC: (GNU) 4.8.2"
.def _printf; .scl 2; .type 32; .endef
然后我又用这个命令编译了它:
gcc -std=c99 -pedantic test.c -O3 -S -o test.asm
这是输出结果
.file "test.c"
.def ___main; .scl 2; .type 32; .endef
.section .rdata,"dr"
LC0:
.ascii "%d\12\0"
.section .text.startup,"x"
.p2align 4,,15
.globl _main
.def _main; .scl 2; .type 32; .endef
_main:
LFB7:
.cfi_startproc
pushl %ebp
.cfi_def_cfa_offset 8
.cfi_offset 5, -8
movl %esp, %ebp
.cfi_def_cfa_register 5
pushl %ebx
andl $-16, %esp
subl $16, %esp
.cfi_offset 3, -12
call ___main
movl 8(%ebp), %eax
leal (%eax,%eax), %edx
movl $1, %eax
cmpl $4, %edx
jne L8
jmp L6
.p2align 4,,7
L12:
movl %ebx, %eax
L8:
leal 1(%eax), %ebx
movl %eax, 4(%esp)
movl $LC0, (%esp)
call _printf
cmpl $11, %ebx
jne L12
L6:
xorl %eax, %eax
movl -4(%ebp), %ebx
leave
.cfi_restore 5
.cfi_restore 3
.cfi_def_cfa 4, 4
ret
.cfi_endproc
LFE7:
.ident "GCC: (GNU) 4.8.2"
.def _printf; .scl 2; .type 32; .endef
基本上,在开启优化后,原始代码就变成了这样。
#include <stdio.h>
int main(int argc, char **argv) {
int dummy = 2 * argc;
int i = 1;
if (dummy != 4)
while (i<=10)
printf("%d\n", i++);
return 0;
}
所以,正如你所看到的,在C语言中确实有葫芦。
其实java中也有葫芦的概念。的代码。
while (!stop)
i++;
可能会转化成这样的代码
if (!stop)
while (true)
i++;
当给定的方法上没有同步块时,JVM确实(允许)进行这种 "优化"。
更多细节可以参考Effective Java, 3rd Edition , 第11章,并发性
C、C++、Java中不存在Hoisting。
对于C++和Java来说,变量声明可以发生在方法或函数中的任何一点,但它必须在使用值之前。 对于C语言来说,它必须在顶部。
在这些语言中,变量作用域要么是全局的,要么是在使用大括号的地方(所以你可以任意在C程序中扔一对大括号,然后引入一个新的变量作用域--在Javascript中,你会使用闭包来实现同样的事情)。