variable declaration style

[John Doe]

Let's say I had code like these, what is better?

for(;
{
bool finished;

do
{
}
while (!finished);
}

or

bool finished;

for(;
{

do
{
}
while (!finished);
}

Whenever declaring variables I tend to think like what a compiler does.
What if a compiler allocates from the stack whenever it finds a variable
definition?

 

[Victor Bazarov]

Let's say I had code like these, what is better?

The former. The simple rule is: unless some other requirement prevents
it, keep the tightest scope for any variable you declare.

for(;
{
bool finished;

do
{
}
while (!finished);
}

or

bool finished;

for(;
{

do
{
}
while (!finished);
}

Whenever declaring variables I tend to think like what a compiler
does. What if a compiler allocates from the stack whenever it finds a
variable definition?

So? It's not specified, the compiler is free to do whatever it sees
fit. Why do you care, anyway?

V

 

[John Doe]

The former. The simple rule is: unless some other requirement prevents

it, keep the tightest scope for any variable you declare.
thanks

So? It's not specified, the compiler is free to do whatever it sees
fit. Why do you care, anyway?

V

because all kinds of allocation take time and, say 10000s of stack
allocations could make an impact on execution time. It figures that it's
unspecified, but what is the rule-of-thumb? What do modern C++ compilers
usually do?

 

[Jacek Dziedzic]

John Doe wrote:
[snip]

because all kinds of allocation take time and, say 10000s of stack
allocations could make an impact on execution time. It figures that it's
unspecified, but what is the rule-of-thumb? What do modern C++ compilers
usually do?

They optimize that away.

- J.

 

[Andrew Koenig]

because all kinds of allocation take time and, say 10000s of stack
allocations could make an impact on execution time. It figures that it's
unspecified, but what is the rule-of-thumb? What do modern C++ compilers
usually do?

Rule of thumb: People are more important than computers. Therefore, you
should strive to make your programs as easy as possible to understand.

If you are concerned about performance, measure the program once it's
complete and working.

 

[Rolf Magnus]

because all kinds of allocation take time and, say 10000s of stack
allocations could make an impact on execution time.

What exactly would you expect a "stack alocation" to look like?

It figures that it's unspecified, but what is the rule-of-thumb? What do
modern C++ compilers usually do?

Probably nothing.

 

[Alf P. Steinbach]

* John Doe:

* Victor Bazarov:


because all kinds of allocation take time and, say 10000s of stack
allocations could make an impact on execution time. It figures that it's
unspecified, but what is the rule-of-thumb? What do modern C++ compilers
usually do?

Stack allocation is mostly a conceptual device, and conceptual
operations do not necessarily take time.

A modern compiler implements the C++ automatic storage stack (LIFO
automatic allocation) by reserving a suitably large chunk of (machine)
stack space on function entry, using one or at most three instructions.

Disregarding function calls, further (machine) stack allocations do not
(typically) take place during execution of the function's code, except
if it uses extensions such as _alloca() or C99 dynamic arrays.
Initializations of local objects can still take time. However, local
variables of built-in types are by default not initialized, and anyway,
modern compilers also do such things as moving invariant code out of
loops, so as others have remarked, /measure/ before trying to optimize.

Btw., please include some mention of whom you're quoting.

I've added back the missing information above.

 

[Mike Wahler]

because all kinds of allocation take time

Some kinds take longer than others.

and, say 10000s of stack allocations could make an impact on execution
time.

First, note that there's no requirement by the language that a stack
be used for anything at all. However, many implementations do indeed
implement local objects and function parameters with a stack. But
on every machine I've worked with, 'allocation' of stack data involves
nothing more than assigning a value to a single register. IMO pretty
darn quick operation.

It figures that it's unspecified, but what is the rule-of-thumb?

Write clear, understandable, maintainable code. Measure performance.
Only consider optimizing at source code level if performance does not meet
specifications. And when doing this, the usual best thing to optimize is
the algorithms, not 'low level' code structure.

What do modern C++ compilers usually do?

They optimize, almost always better than a coder could.

-Mike

 

[Adrian Hawryluk]

Let's say I had code like these, what is better?

for(;
{
bool finished;

do
{
}
while (!finished);
}

or

bool finished;

for(;
{

do
{
}
while (!finished);
}

Neither, finished is not initialised, so what finished will result in
causing the loop to terminate is going to be random. However, if you
initialise the finished variable, you will want to do the former for the
same reasons that were already stated in the rest of the thread.


Adrian

Whenever declaring variables I tend to think like what a compiler does.
What if a compiler allocates from the stack whenever it finds a variable
definition?

Yeah, that is sometimes good in low level hardware apps using old
compilers when every clock cycle counts, but the allocation of memory on
the stack is not as big a deal as the initialisation, and you will have
to initialise it some where anyway, so you might as well do it at
initialisation. The optimiser will take care of a whole whack of
things, but mistake proofing is not one of them. Write your code to
keep mistakes from happening and let the optimiser do its job.


Adrian

 

[SasQ]

Dnia Thu, 08 Mar 2007 17:17:23 +0100, John Doe napisa³(a):

Not all kinds Only the dynamic ones [new/delete].
Local objects are being allocated on the stack by
decreasing stack pointer to make it point "above"
the allocated local objects' total size.

and, say 10000s of stack allocations could make
an impact on execution time.

Instructions also have impact on execution time

It figures that it's unspecified, but what is the
rule-of-thumb? What do modern C++ compilers usually do?

Modern compilers I know makes allocation of all local
objects of a particular block once a time [on the block
entry] by establishing a stack frame [remembering the
stack pointer in the base register, and decreasing the
stact pointer by the total size of all local objects],
and "deallocate" it upon exit from that block [by
restoring the old value of stack pointer].

 

[Sanjay Kulkarni]

Hi,

I am an amateur programmer who keeps on lurking on this forum to pick
up a few tit-bits of tips here and there.

I haven't understood complexity of the solutions provided. This is how
I see the problem:

The thing wrong with the code

for(;
{
bool finished;

do
{

} while (!finished);
}

in my opinion is the variable 'finished' is declared - unnecessarily -
repeatedly. A thumb of rule I learnt is that such a thing is an
unefficient programming practice.

Another rule of thumb that was posted earlier is that the scope of the
variable should be as tight as possible.

What is wrong with following two solutions which satisfy both of the
above rules?

{
bool finished;
for(;
{
do
{

} while (!finished);
}
}

OR

for(;
{
static bool finished;
do
{

} while (!finished);
}
}

- Sanjay Kulkarni
===============

 

[=?ISO-8859-15?Q?Juli=E1n?= Albo]

What is wrong with following two solutions which satisfy both of the
above rules?

{
bool finished;
for(;
{
do
{

} while (!finished);
}
}

You can use a shorter and simpler approach:

for (bool finished= false; ! finished; )
{
// Whatever
}

 

[Rolf Magnus]

Hi,

I am an amateur programmer who keeps on lurking on this forum to pick
up a few tit-bits of tips here and there.

I haven't understood complexity of the solutions provided. This is how
I see the problem:

The thing wrong with the code

for(;
{
bool finished;

do
{

} while (!finished);
}

in my opinion is the variable 'finished' is declared - unnecessarily -
repeatedly. A thumb of rule I learnt is that such a thing is an
unefficient programming practice.

That's very unlikely to be inefficient. If you have a complex object that
needs lots of initialization, then repeatedly creating it might become
inefficient, but that's not the case for bool.

Another rule of thumb that was posted earlier is that the scope of the
variable should be as tight as possible.

Yes. I'd prefer that over the other one.

What is wrong with following two solutions which satisfy both of the
above rules?

{
bool finished;
for(;
{
do
{

} while (!finished);
}
}

OR

for(;
{
static bool finished;
do
{

} while (!finished);
}
}

Which problem are you trying to solve? None of those versions should be any
faster than the one with a simple bool variable inside the for loop.