While(1) or for(;;) for infinite loops?

[Roopesh]

It's actually pretty close to Fortran:

do
  ...
enddo

James Tursa

I think that both are same, either you go with for(; or while(1).
But i guess, on the internal workings, while(1) is far better than for
(; [ even though, for(; is cleaner to read ]. The reason being,
while implementing the for(;, the code has to maintain an internal
variable, for incrementing it and checking for infinity [ Correct me
if am wrong ], whereas in the case of while(1), its just a flag check
and nothing more.

So, i would prefer to use while(1) than for(;, at the cost of the
readability.

Roopesh.

 

[bartc]

You're right. I nodded.
It's very common to see programs which do a bit of set up, then enter an
infinite loop (a typical one is a message loop from a GUI). However you
could have a program with two or more infinite loops which switches
between them depending on conditions. You could even (though rarely) have
the first infinite loop broken by an external signal, and then enter the
second.

I used infinite loop to mean one which uses an explicit break somewhere in
the body.

I use them all the time, mainly because when I start to write one, I have
little idea how I'm going to jump out it. And later I don't bother to change
it to conventional form.

 

[Eric Sosman]

You can have only one infinite loop in a program.

You can have more than one, it's just you will only reach one of them on
any given run. [...]

for (; {
while (1) {
do {
otog:
...
goto otog;
} while (1);
}
}

 

[Nick Keighley]

I used infinite loop to mean one which uses an explicit break somewhere in
the body.

whilst other people use it to mean a loop that *never* terminates.
I've probably described for(; as "an infinite loop" even when I've
been sure it does terminate. But that is a a bit sloppy.

I use them all the time, mainly because when I start to write one, I have
little idea how I'm going to jump out it.

eeek! How can you write a loop without knowing how it will terminate!
Surely you construct the loop-invarient and termination criteria
*before* you write the loop!

And later I don't bother to change
it to conventional form.

I use the construct when none of the normal C-loop forms will do. That
is I want to break out of the middle of the loop. You can use an extra
boolean variable but sometimes that seems contrived.

for (;
{
skip_leading_whitespace (stream);

if (!build_msg (msg, stream))
break; /* <-- break out of loop */

process_msg (msg);
}

 

[Not Really Me]

That's a minor detail. I don't think allowing an empty condition on
while(), to match the empty one in for(;, or taking those two
semicolons as read (since they are not separating or terminating
anything), is too taxing for compiler maintainers.

(And for all I know, extensions might already exist for those.)


No, that's a completely different syntax style and certainly not C.
I'm talking about being allowed to leave out one or two characters
which don't contribute anything.

Aargh! Sorry but I was hoping for "valid" reaons. In C99, the conditions
are stated as optional in a for statement, but they are mandatory for while.

--
Scott
Validated Software
Lafayette, CO



__________ Information from ESET NOD32 Antivirus, version of virus signature database 4667 (20091207) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

 

[Not Really Me]

Sorry for the digression, but:

Using Pascal in college, my friend liked to use the significantly
less-clean:

repeat
...
until false;

which always made me giggle.

-Beej

That's as bad as my friend who liked:

#define WahDiddy while(1)

do {
...
} WahDiddy;

Maybe you had to grow up in the sixties here in the US.

__________ Information from ESET NOD32 Antivirus, version of virus
signature database 4667 (20091207) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

__________ Information from ESET NOD32 Antivirus, version of virus signature database 4667 (20091207) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

 

[Not Really Me]

No.

Thanks Pete. Best answer of the bunch. It is what I expected, but I needed
to ask.

--
Scott
Validated Software
Lafayette, CO



__________ Information from ESET NOD32 Antivirus, version of virus signature database 4667 (20091207) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

 

[Keith Thompson]

my point was they didn't wait 31/32 years before adding new syntax.
They waited 10. And more new syntax was added in 1999.

I think Adrian's point was that significant new syntax (prototypes and
"...") was added once in that 31/32 year period (the C99 syntax
changes were relatively minor).

 

[Flash Gordon]

I think that both are same, either you go with for(; or while(1).
Yes.

But i guess, on the internal workings, while(1) is far better than for
(;

No. I would say the reverse.

[ even though, for(; is cleaner to read ]. The reason being,
while implementing the for(;, the code has to maintain an internal
variable, for incrementing it and checking for infinity [ Correct me
if am wrong ],

You are wrong. C for loops to not rely on a loop counter even
conceptually. for (; reads...
Do no initialiastion
{
Do not check a condition
Do loop body
Do not do anything for moving on to the next iteration
}
So the for loop is saying explicitly that you do not have a condition.

In C, if you want a conceptual loop counter you have to explicitly
provide it.

whereas in the case of while(1), its just a flag check
and nothing more.
True.

So, i would prefer to use while(1) than for(;, at the cost of the
readability.

Well, your reasoning is wrong. In any case, the compiler can implement
it with an unconditional jump, and I've yet to see one that implements a
test.

 

[scattered]

I assume this has come up before but I am getting nowhere with searches.

To make an infinite loop, while(1) tends to generate lint/compiler warnings,
for(; does not.

Other than personal preference, are there any other technical reasons to
pick one over the other?

I will stipulate for the argument that performance is identical.

--
Scott
Validated Software
Lafayette, CO

__________ Information from ESET NOD32 Antivirus, version of virus signature database 4661 (20091204) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

A bit silly perhaps but I like the following:

Use the preprocessor directive

#define EVER ;;

then you can use

for(EVER)
{
stuff
}

for the infinite loop

 

[Flash Gordon]

On Dec 5, 2:02 pm, James Tursa <[email protected]>
wrote:

loop
...
end loop;
but that's not C either.
No, that's a completely different syntax style and certainly not C.
It's actually pretty close to Fortran:

do
...
enddo

James Tursa
I think that both are same, either you go with for(; or while(1). Yes.

But i guess, on the internal workings, while(1) is far better than for
(;

No. I would say the reverse.

[ even though, for(; is cleaner to read ]. The reason being,
while implementing the for(;, the code has to maintain an internal
variable, for incrementing it and checking for infinity [ Correct me
if am wrong ],

You are wrong. C for loops to not rely on a loop counter even
conceptually.

You are wrong. Most/a huge percentage of C for loops do indeed rely on
a loop counter.

You missunderstood me. The C for loop does not rely on a loop counter.
Of course, many loops make use of a loop counter, and as I stated, but
you snipped without marking the snippage, when you use a loop counter
you have to do so explicitly.

It is also clear from what the OP posted what I was refuting.

 

[Eric Sosman]

A bit silly perhaps but I like the following:

Use the preprocessor directive

#define EVER ;;

then you can use

for(EVER)
{
stuff
}

for the infinite loop

When I was young and stupid, I used to write

#define until(x) while(!(x))

so I could have `do { something } until(condition);'. It took
me a while to understand that this made my code *less* readable
rather than more, because the reader encountering the latter had
to stop and go hunt for the definition of `until'. Interrupting
the reader's train of thought was not helpful.

Somebody handed down a Commandment along the lines of "Thou
shalt not use the preprocessor to muck up the syntax," but I
can't find the original and don't know the identity of the God
whose command it was. Personally, I think it must have been a
false God, because every so often one comes across an inspired
use that *does* do violence to the syntax, and does it for a
good reason. But things like `until' and `EVER' are just silly;
"beautiful new impediments to understanding" as the real, true
Ten Commandments puts it.

 

[Ben Pfaff]

Somebody handed down a Commandment along the lines of "Thou
shalt not use the preprocessor to muck up the syntax," but I
can't find the original and don't know the identity of the God
whose command it was. Personally, I think it must have been a
false God, because every so often one comes across an inspired
use that *does* do violence to the syntax, and does it for a
good reason. But things like `until' and `EVER' are just silly;
"beautiful new impediments to understanding" as the real, true
Ten Commandments puts it.

My favorite additions to syntax are macros that allow one to
iterate over a custom data structure without manually writing out
extensive "for (...)" syntax.

 

[Charlie Gordon]

Thanks Pete. Best answer of the bunch. It is what I expected, but I
needed to ask.

Actually, there is one technical reason that has not been mentioned yet...
Funny it took pete's blunt answer to make me remember it:

for(; is a blunt, obvious looping contruct.

while(1) on the other hand can be confused with while(l)

this is imho a good reason to avoid both while(1) and local variables named
l

 

[Keith Thompson]

Actually, there is one technical reason that has not been mentioned yet...
Funny it took pete's blunt answer to make me remember it:

for(; is a blunt, obvious looping contruct.

while(1) on the other hand can be confused with while(l)

this is imho a good reason to avoid both while(1) and local variables named
l

Interesting.

I've seen the visual similarity of the digit '1' and the letter
'l' presented as a reason (and a very good one IMHO) to avoid using
'l' as an identifier. I've never seen it presented as a reason to
avoid using the number 1.

 

[Lew Pitcher]

Actually, there is one technical reason that has not been mentioned yet...
Funny it took pete's blunt answer to make me remember it:

for(; is a blunt, obvious looping contruct.

while(1) on the other hand can be confused with while(l)

So? Instead of a constant 1, the programmer /could/ use any other non-zero
integral value. Thus
while (2)
is just as effective, and few people would confuse a 2 with a C identifier.

But, perhaps even better (from the readability point of view) would be to
use a tautology
while (1 == 1)
or
while (7 != 6)
accomplishes the same thing, but with an obvious "truth" value

this is imho a good reason to avoid both while(1) and local variables
named l

Having said all that, I prefer
for (;
over
while (1)

The programmer / reader has to evaluate the condition in the while () loop
and determine if it will always evaluate to true. Trivial for while (1) or
while (0), but not so trivial for other conditions. OTOH, the for (;
template leaves the reader/programmer with nothing to evaluate; if they see
no terminating condition, the loop doesn't terminate.

I know that these are trivial reasons, but that's how /I/ make my choice as
to which looping construct I'll use for infinite loops. Heck, it could be
worse. I /could/ use
some_label:;
/**/
goto some_label;

 

[scattered]

     When I was young and stupid, I used to write

        #define until(x) while(!(x))

so I could have `do { something } until(condition);'.  It took
me a while to understand that this made my code *less* readable
rather than more, because the reader encountering the latter had
to stop and go hunt for the definition of `until'.  Interrupting
the reader's train of thought was not helpful.

     Somebody handed down a Commandment along the lines of "Thou
shalt not use the preprocessor to muck up the syntax," but I
can't find the original and don't know the identity of the God
whose command it was.  Personally, I think it must have been a
false God, because every so often one comes across an inspired
use that *does* do violence to the syntax, and does it for a
good reason.  But things like `until' and `EVER' are just silly;
"beautiful new impediments to understanding" as the real, true
Ten Commandments puts it.

--
Eric Sosman
(e-mail address removed)- Hide quoted text -

- Show quoted text -

Good advice - it's not like the idiom for(;{...} is that hard to
understand. On the other hand, I am basically a hobby programmer who
doesn't forsee my code ever being read let alone maintained by others,
so sometimes I adopt little idiosyncratic conventions for my own use.

 

[Nick Keighley]

I think Adrian's point was that significant new syntax (prototypes and
"...") was added once in that 31/32 year period (the C99 syntax
changes were relatively minor).

designated initialisers?

 

[Nick Keighley]

Interesting.

I've seen the visual similarity of the digit '1' and the letter
'l' presented as a reason (and a very good one IMHO) to avoid using
'l' as an identifier.  I've never seen it presented as a reason to
avoid using the number 1.

1 (one) is one of the few numeric constants I allow in my code. 0
(zero) being the other one. Oh, ok some masks might sneak in.

 

[Nick Keighley]

Good advice - it's not like the idiom for(;{...} is that hard to
understand. On the other hand, I am basically a hobby programmer who
doesn't forsee my code ever being read let alone maintained by others,
so sometimes I adopt little idiosyncratic conventions for my own use.

eventually though you become "the other".

Believe me, some of your old code will eventually look very odd to
you!