Thread: Defining variables in C++ as late as possible?

Hi.
Here's a quote from C++ Primer - Fifth Edition:

Advice: Define Variables Where You First Use Them

It is usually a good idea to define an object near the point at which the
object is first used. Doing so improves readability by making it easy to find
the definition of the variable. More importantly, it is often easier to give the
variable a useful initial value when the variable is defined close to where it is
first used.

While I can see why that kind of practice is beneficial (defining variables as late as possible, besides what the book pointed out,
also minimizes their scope, and consequently reducing bugs potential - at least that's my take on it),
I don't understand why in C, in a course I took a couple of years ago, I was encouraged to do the opposite - "define any variable you'll use in advance,
at the head of the function body".
Is there some performance advantage in C when defining variables in advance, that doesn't exist in C++?
Or maybe I was provided with misinformation in that course?

> I was encouraged to do the opposite - "define any variable you'll use in advance, at the head of the function body".
The problem is that historically (prior to C99), that was your only choice.
If you want to retain maximum compiler compatibility, then you have to declare all your function variables at the start of a block.

You can mimic C++ / C99 behaviour by placing declarations / code inside additional open/close brace pairs.

Originally Posted by MutantJohn

Did you have to do it in the beginning because of how the stack works?

That's not how the stack works.
To be fair, the stack works differently in different operating systems, but the generally known approach I can describe.
Typically, the stack is implemented somewhere in memory with a specific register pointing to the top of the stack.
To place a variable on the stack, you either:
- Use dedicated instructions such as push, or
- Use general instructions such as mov to move data to a specific offset of the memory as pointed to by the stack pointer register.
To reserve space, you usually simply subtract a constant to the stack pointer register. To deallocate, you just add a constant.
This implies that you can just use an add instruction or push instruction at any time to put new stuff on the stack or remove stuff.
The stack is not some fixed thing that is created at the beginning of a function from a processor's point of view.
However, due to optimizations, compilers often reserve the necessary stack space at the top of a function and deallocates it at the end.

Originally Posted by Absurd

Hi.
Here's a quote from C++ Primer - Fifth Edition:


While I can see why that kind of practice is beneficial (defining variables as late as possible, besides what the book pointed out,
also minimizes their scope, and consequently reducing bugs potential - at least that's my take on it),
I don't understand why in C, in a course I took a couple of years ago, I was encouraged to do the opposite - "define any variable you'll use in advance,
at the head of the function body".
Is there some performance advantage in C when defining variables in advance, that doesn't exist in C++?
Or maybe I was provided with misinformation in that course?

I disagree. If I run across a variable halfway down the page of code and it's not its first use, how do I know where its definition is? I have to search all through the code up to that point to find the definition. By that time I've lost the train I was riding. It's better IMO to use the C way. You always know where the definitions are for a quick refresh.

Originally Posted by WaltP

I disagree. If I run across a variable halfway down the page of code and it's not its first use, how do I know where its definition is? I have to search all through the code up to that point to find the definition. By that time I've lost the train I was riding. It's better IMO to use the C way. You always know where the definitions are for a quick refresh.

You use your IDE's go to definition feature. It will helpfully open a new little window inside your first showing you the definition. But then again, why do you need to see the definition? All you really need to know is its type.
Besides, we all know that we should, if possible, not reuse variables. Compilers don't like it. And apparently, according to you, we don't like it, either.

Originally Posted by Elysia

we should, if possible, not reuse variables. Compilers don't like it.

I've never heard that before. Do compilers have a harder time optimizing code if a variable is reused multiple times?

I'll give you a real-life example of something that I do:

I often declare an int called "bytes" to store the return value of send() and recv(). My code first reads a few bytes from the socket to determine the total length of the message, and then reads the whole message in a loop. Are you saying it's bad to use the same "bytes" variable in the loop that I used previously when I read the message length?

Originally Posted by Elkvis

I've never heard that before. Do compilers have a harder time optimizing code if a variable is reused multiple times?

Yes, they do. A compiler needs to do a lifecycle analysis to determine how long variables live. If you reuse it elsewhere, then you are artificially "prolonging" said variable's lifetime. The compiler needs to know how long variables live in order to see what variables it can put into registers and when it can reuse said registers. You can look a little on liveness analysis if you're interested.
Granted, compilers these days are pretty sophisticated, so they can probably break such dependencies, but I have no experience or knowledge of such things.
So this probably is a "micro optimization" (given that caches exist if the compiler can't break the dependency chain).

Originally Posted by MutantJohn

Did you have to do it in the beginning because of how the stack works? That when you're switching stack frames all the allocations are made at once in the very beginning? So before compilers were smart enough to parse a file for all stack-based declarations, it was simplest to just have the user put them all in the same section.

Yeah, that's pretty much it.

Originally Posted by Elysia

That's not how the stack works.
To be fair, the stack works differently in different operating systems, but the generally known approach I can describe.
Typically, the stack is implemented somewhere in memory with a specific register pointing to the top of the stack.
To place a variable on the stack, you either:
- Use dedicated instructions such as push, or
- Use general instructions such as mov to move data to a specific offset of the memory as pointed to by the stack pointer register.
To reserve space, you usually simply subtract a constant to the stack pointer register. To deallocate, you just add a constant.
This implies that you can just use an add instruction or push instruction at any time to put new stuff on the stack or remove stuff.
The stack is not some fixed thing that is created at the beginning of a function from a processor's point of view.
However, due to optimizations, compilers often reserve the necessary stack space at the top of a function and deallocates it at the end.

It's true that you can push things on the stack in the middle of a function, but then you have to manually keep track of what to pop off at the end of the function, which can be tricky with multiple return points. So usually you would allocate all the stack space at the beginning of the function, and pop it off the stack at the end. That's how you would do it in assembly, and that's how you had to do it in early C.