C语言程序开发中,变量定义的位置影响程序效率吗?

C语言程序开发不像 Python,若是需要使用变量,必须先定义。仔细想一想,C语言这么要求的原因也是容易理解的,至少C程序可以事先知道需要为该变量分配多少内存,这其实也是C语言程序更可控的原因之一。

C语言程序的变量

虽然“定义再使用”目的是为了使用更小的开销,实现更高的效率,但是很多程序员仍然将它看作是一种落后低效的特性。就代码编写而言的确如此,这增加了整个代码的复杂度。

特别是在 C89 时代,C语言程序员在定义变量时,必须将所有变量定义在语句的开头。下面这段C语言代码是非法的:

printf("hello \n");
int i = 3;
printf("i= %d\n", i);

强制所有变量语句的开头定义是非常反人类的做法——若是某个C语言代码块使用的变量稍多,很难写出易读的代码。因此C99抛弃了这种限制,允许程序员混合语句和变量定义表达式。这样一来,我们可以将要使用的变量定义在附近,写出更加简洁易读的C语言代码:

int i;
fun1(&i);
...
float f;
fun2(&f);

问题

C语言程序员在支持C99标准的平台开发程序,可以将变量定义表达式定义在任意位置。那么一个有趣的问题就出现了,请看下面这段C语言代码:

int fun ()
{
  if (!somecondition) return false;

  internalStructure  *str1;
  internalStructure *str2;
  char *dataPointer;
  float xyz;
}

作为示例,fun() 函数的代码很简单,读者应将注意力放在下面的定义变量上,显然,这几行变量定义代码既可以放在 if() 表达式前面,也可以放在后面。若是 if() 表达式为真,提前让 fun() 函数返回,那么是不是在其后定义的变量就不会被执行了呢?

换句话说,这样的情况下,将变量定义语句放在 if() 表达式之前,和之后,有没有性能上的差异呢?到底应该放在前面还是后面呢?

讨论

首先应该明白的是,C99 标准允许程序员混合语句和变量定义表达式的目的就是为了代码更加清晰易读,基于这一点,当前的C语言程序编码风格是尽可能的将变量声明放在接近其被使用的地方。

实际上,鉴于几乎所有处理器都使用栈指针管理程序栈,从机器的角度来看,在C语言程序中将变量定义在任意位置都是相同的。例如下面这两个函数:

int foo() {
    int x;
    return 5;
}

int bar() {
    int x;
    int y;
    return 5;
}

如果使用现代C语言编译器处理这段代码,并且不指定优化项,会得到下面这样的指令集(以x64平台为例):

foo:
push ebp
mov  ebp, esp
sub  esp, 8
mov  eax, 5
add  esp, 8
ret

bar:
push ebp
mov  ebp, esp
sub  esp, 16
mov  eax, 5
add  esp, 16
ret

看不懂也没关系,至少我们能够看出,两个函数具有相同数量的操作码。这是因为几乎所有的编译器都会预先分配它们所需的所有空间,机器不能做任何不能确定的事情。

现代编译器大都会做一些特别的处理,以使我们的C语言代码获得更高的效率。例如,编译器可以将一些局部变量优化到寄存器中。

出于同样的原因,编译器将收集所有的局部变量声明,并为它们预先分配空间。C89要求所有变量定义放在最前面,是因为它被设计为成一次通过的编译器,它需要在处理其他代码之前知道所有的变量。

C99则聪明得多,即使程序员将变量定义在代码的后面也是可以的,因为它会向后检查更多的代码,将所有变量定义放在其他语句之前处理,本质上来说,它和C89没有区别,只不过做了更多的工作,方便程序员编写代码而已。

所以,在编写C语言程序时,我们更应该考虑的是怎样让代码更加清晰易懂。就本例而言,将变量定义放在if语句前后,并不会带来效率上的差异。

小结

在C99之后,程序员可以混合变量定义和其他语句。读者应注意,C99做出这样的改进,目的在于方便程序员写出更加清晰易懂的代码,考虑将变量定义放在不同位置以获得效率性能上的提升倒没那么苛刻了。一般来说,将变量定义放在最靠近它被使用的地方是比较推荐的做法,当然了,读者也大可不必局限于此,写出清晰易读,效率优异的程序才是最终目的。

https://stackoverflow.com/questions/27729930/is-declaration-of-variables-expensive

阅读更多:   C语言
添加新评论

icon_redface.gificon_idea.gificon_cool.gif2016kuk.gificon_mrgreen.gif2016shuai.gif2016tp.gif2016db.gif2016ch.gificon_razz.gif2016zj.gificon_sad.gificon_cry.gif2016zhh.gificon_question.gif2016jk.gif2016bs.gificon_lol.gif2016qiao.gificon_surprised.gif2016fendou.gif2016ll.gif