how to do an infinite loop

[Sohail Somani]

Aren't busy loops bad for energy consumption?

Yep. I haven't done it for a while (8051 micro), but at the very least
you should use timers + interrupt functions.

 

[Flash Gordon]

Juha Nieminen wrote, On 19/11/07 20:04:

Aren't busy loops bad for energy consumption?

An infinite busy loop would be, but I don't think that is what Miguel
was suggesting. I've done an infinite loop of the form:

for (; {
suspend_processor();
do_something();
}

On another project:

for (; suspend_processor();

In each case, suspend_processor() stops the processor from executing
code until it receives an interrupt.

 

[Juha Nieminen]

An infinite busy loop would be, but I don't think that is what Miguel
was suggesting. I've done an infinite loop of the form:

for (; {
suspend_processor();
do_something();
}

On another project:

for (; suspend_processor();

In each case, suspend_processor() stops the processor from executing
code until it receives an interrupt.

It's a kind of processor which simply continues execution from where
it left it when it receives an interrupt instead of jumping to an
interrupt handler defined in some interrupt table?

 

[Flash Gordon]

Juha Nieminen wrote, On 19/11/07 22:59:

It's a kind of processor which simply continues execution from where
it left it when it receives an interrupt instead of jumping to an
interrupt handler defined in some interrupt table?

No. It does the interrupt processing then returns and executes
do_something (in the first case). Also note that the second example does
*nothing* in the main loop apart from suspend the processor.

The most common processor I've done this kind of loop on is the Z80, but
I've also used it on the TMS320C25 and maybe other processors.

 

[Joel Yliluoma]

Juha Nieminen wrote, On 19/11/07 22:59:

It does the interrupt processing then returns and executes
do_something (in the first case). Also note that the second
example does *nothing* in the main loop apart from suspend
the processor.
The most common processor I've done this kind of loop on is the
Z80, but I've also used it on the TMS320C25 and maybe other processors.

As an interesting part of trivia, the main loop of Super Mario Bros. on
the 8-bit Nintendo is exactly of this kind. The main loop does literally
nothing else but wait for the next interrupt. (Except that the NES does
not have a suspend/wait opcode, so it was a for(;; loop instead.)

Most other NES games defaulted to the busyloop once they had
done processing the game logic of that particular display frame;
some constantly updating the random number generator seed in that loop.

Follow-ups set.

 

[Charlie Gordon]

(e-mail address removed) said:


Oops, good point.

Then I'd do it like this:

do
{
if(condition = yadayada())
{
moreyadayada();
}
} while(condition);

Simple logic, obvious control flow, no wild jumps, everything nicely
encapsulated in functions.

Contorted syntax for simple logic that is better expressed as:

for (; {
<yadayada...>

if (<condition>)
break;

<moreyadiyada...>
}

What is not obvious about this?

Encapsulating in functions, while advisable in many cases, may not be
pratical in others.

The added advantage of this approach appears when condition can be produced
and tested in multiple places inside the loop. You proposal would lead to
artifical deeply nested if chains.

Furthermore, assignment in a test expression is error prone and hard to
read. In order to prevent errors, I advise everyone to make their compile
produce warnings for such constructs. Also worth noting is that many
compilers will not optimize the final redundant test in the do/while loop,
leading to useless inefficiencies.

Finally, condition may be an arbitrary expression, with potential side
effetcs. With your proposed alternative, one needs to declare an extra
local variable to store it... more artificial work arounds.

 

[Charlie Gordon]

James Kuyper said:


(Hear hear.)


If you need to exit the loop "in the middle": while(1) { condition =
foo();
if(!condition) { break; } bar(); } it's always because of an exit
condition that may or may not be true, that you must test. (Were this not
so, you wouldn't be using a loop.) The obvious way to deal with such a
situation is:

while(foo())
{
bar();
}


for(yadayada(); condition; moreyadayada())
{
}

is clearer still, no?

Certainly not!
Even barring the fact that it implements different semantics ;-)


What is not clear about the for (; loop is the *hiding* if the exit test.
If you make it stand out as it should, separating it from yadiyada with
blank lines and breaking the break on a separate line, it becomes obvious.
After seeing for (;, he reader knows what to look for: either a break or a
return will exit the loop.

Right.

That is your opinion, not an obsolute truth.

 

[Charlie Gordon]

How about:

do {
/* yada yada */
if (!exit_condition) {
/* more yada yada */
}
} while (!exit_condition);

fups set for c.l.c. Cross posting to c.l.c++ is unwise.

<exit condition> is an arbitrary expression, your proposed alternative
requires at least an extra local variable definition. It may also produce
extra code for the redundant test. IME neebies tend to produce more bugs
when using do/while loops... but that's another can of worms.

 

[Charlie Gordon]

pete said:


That's not for C/C++, but for C-C++.

C/C++ and C-C++ both invoke undefined behaviour.

 

[Charlie Gordon]

James Watt wrote:
can anyone tell me how to do an infinite loop in C/C++, please ?
There being no such language as C/C++, it is impossible to do anything
with it.

Actually, this came up in a job offer that explicitly listed, and I quote

...experience in C/C++ [is] an advantage, but not a requirement...

Are you saying there is no such thing?

[...]

Correct, there is no such language as "C/C++". C and C++ are two distinct
(but closely related) languages.

People often use the term "C/C++" as if it were the name of a language.
The charitable interpretation of this is that it really means "C and C++",
or "C or C++", or "C and/or C++".

Or perhaps "C || C++", which means that if C is good enough, you don't
need to go on to C++. }

More precisely ;-)

- if C has a non zero value, the Standard requires that C++ not be
evaluated.
- if C has a zero value, so does C++, and in the end C will have non zero
value.

 

[Philip Potter]

C/C++ and C-C++ both invoke undefined behaviour.

Not necessarily:

#define C x,y