Is declaration of variables expensive?

Question

While coding in C, I came across the below situation.

int function () {   if (!somecondition) return false;    internalStructure  *str1;   internalStructure *str2;   char *dataPointer;   float xyz;    /* do something here with the above local variables */     } 

Considering the if statement in the above code can return from the function, I can declare the variables in two places.

1. Before the if statement.
2. After the if statement.

As a programmer, I would think to keep the variable declaration after if Statement.

Does the declaration place cost something? Or is there some other reason to prefer one way over the other?

Answer 1

In C99 and later (or with the common conforming extension to C89), you are free to mix statements and declarations.

Just as in earlier versions (only more so as compilers got smarter and more aggressive), the compiler decides how to allocate registers and stack, or do any number of other optimizations conforming to the as-if-rule.
That means performance-wise, there's no expectation of any difference.

Anyway, that was not the reason such was allowed:

It was for restricting scope, and thus reducing the context a human must keep in mind when interpreting and verifying your code.

Answer 2

Do whatever makes sense, but current coding style recommends putting variable declarations as close to their usage as possible

In reality, variable declarations are free on virtually every compiler after the first one. This is because virtually all processors manage their stack with a stack pointer (and possibly a frame pointer). For example, consider two functions:

int foo() {     int x;     return 5; // aren't we a silly little function now }  int bar() {     int x;     int y;     return 5; // still wasting our time... } 

If I were to compile these on a modern compiler (and tell it not to be smart and optimize out my unused local variables), I'd see this (x64 assembly example.. others are similar):

foo: push ebp mov  ebp, esp sub  esp, 8    ; 1. this is the first line which is different between the two mov  eax, 5    ; this is how we return the value add  esp, 8    ; 2. this is the second line which is different between the two ret  bar: push ebp mov  ebp, esp sub  esp, 16    ; 1. this is the first line which is different between the two mov  eax, 5     ; this is how we return the value add  esp, 16    ; 2. this is the second line which is different between the two ret 

Note: both functions have the same number of opcodes!

This is because virtually all compilers will allocate all of the space they need up front (barring fancy things like alloca which are handled separately). In fact, on x64, it is mandatory that they do so in this efficient manner.

(Edit: As Forss pointed out, the compiler may optimize some of the local variables into registers. More technically, I should be arguing that the first varaible to "spill over" into the stack costs 2 opcodes, and the rest are free)

For the same reasons, compilers will collect all of the local variable declarations, and allocate space for them right up front. C89 requires all declarations to be up-front because it was designed to be a 1 pass compiler. For the C89 compiler to know how much space to allocate, it needed to know all of the variables before emitting the rest of the code. In modern languages, like C99 and C++, compilers are expected to be much smarter than they were back in 1972, so this restriction is relaxed for developer convenience.

Modern coding practices suggest putting the variables close to their usage

This has nothing to do with compilers (which obviously could not care one way or another). It has been found that most human programmers read code better if the variables are put close to where they are used. This is just a style guide, so feel free to disagree with it, but there is a remarkable consensus amongst developers that this is the "right way."

Now for a few corner cases:

• If you are using C++ with constructors, the compiler will allocate the space up front (since it's faster to do it that way, and doesn't hurt). However, the variable will not be constructed in that space until the correct location in the flow of the code. In some cases, this means putting the variables close to their use can even be faster than putting them up front... flow control might direct us around the variable declaration, in which case the constructor doesn't even need to be called.
• alloca is handled on a layer above this. For those who are curious, alloca implementations tend to have the effect of moving the stack pointer down some arbitrary amount. Functions using alloca are required to keep track of this space in one way or another, and make sure the stack pointer gets re-adjusted upwards before leaving.
• There may be a case where you usually need 16-bytes of stack space, but on one condition you need to allocate a local array of 50kB. No matter where you put your variables in the code, virtually all compilers will allocate 50kB+16B of stack space every time the function gets called. This rarely matters, but in obsessively recursive code this could overflow the stack. You either have to move the code working with the 50kB array into its own function, or use alloca.
• Some platforms (ex: Windows) need a special function call in the prologue if you allocate more than a page worth of stack space. This should not change analysis very much at all (in implementation, it is a very fast leaf function that just pokes 1 word per page).