Is it okay if I use a lot of while(true) loops?

A

Alexander

In my code I usually find it much simpler to use a while(true) (or
do ... while(true)) loop instead of putting a real condition, and make
a test inside the body of the loop. Usually I find it much more
comfortable to check manually.

So, if you were reading my code, would you dislike this?
 
F

Francesco S. Carta

In my code I usually find it much simpler to use a while(true) (or
do ... while(true)) loop instead of putting a real condition, and make
a test inside the body of the loop. Usually I find it much more
comfortable to check manually.

So, if you were reading my code, would you dislike this?

It depends on the cases. Sometimes the infinite loop is just the wrong
choice (tell me you don't use them for iterating through a std::vector).

I do find infinite loops useful, I accept "while(true)" but I prefer
"for(;;)", and finally I really see no usefulness in "do ...
while(true)" - unless the target is to wear out your keyboard ;-)

If you want more specific opinions, post some example.
 
J

Jonathan Lee

In my code I usually find it much simpler to use a while(true) (or
do ... while(true)) loop instead of putting a real condition, and make
a test inside the body of the loop. Usually I find it much more
comfortable to check manually.

So, if you were reading my code, would you dislike this?

The loop-and-a-half practice is common enough that no one should
have difficulty reading it. Unless, of course, the loop is HUGE
and it's difficult to find the break. Or if there's multiple
break-s. That might be annoying.

In general, though, there are plently of places where it makes
sense. It's also preferable (for me) than unrolling the half
loop and rewriting it as a while(condition) {}. The latter
creates code duplication and often causes variables local to
the while(true){} to be declared one scope higher. Duplication
can introduce maintainability problems. (WRT scope I just
prefer things as limited as possible).

--Jonathan
 
T

tni

In my code I usually find it much simpler to use a while(true) (or
do ... while(true)) loop instead of putting a real condition, and make
a test inside the body of the loop. Usually I find it much more
comfortable to check manually.

So, if you were reading my code, would you dislike this?

If you can reduce complexity/duplication that way (duplicate condition
checking, introducing flag variables, ...), by all means go for it.

If you were to write a simple for loop like:
for(int i = 0; i < len; i++) { ... }
as while(true) loop, I would fire you (if I were your boss anyway).
 
J

James Kanze

In my code I usually find it much simpler to use a while(true) (or
do ... while(true)) loop instead of putting a real condition, and make
a test inside the body of the loop. Usually I find it much more
comfortable to check manually.
So, if you were reading my code, would you dislike this?

Very. At the top of the loop, you say it's forever. If it's
not, then you've lied to the reader of your program.
 
G

Gennaro Prota

Very. At the top of the loop, you say it's forever. If it's
not, then you've lied to the reader of your program.

Although the lie is often very easy to spot :)

(Seriously, yes, I dislike it.)
 
F

Francesco S. Carta

Well, it always is a lie - such a promise can't ever be proved as
fulfilled ;-)

No, that doesn't really reflect what I meant to say. "You can never
prove it's not a lie", that works better.
 
T

tni

Very. At the top of the loop, you say it's forever. If it's
not, then you've lied to the reader of your program.

No, you haven't. It's almost always used in conjunction with break (real
infinite loops are quite rare). This pattern is so common that that Qt
has a special keyword 'forever'.

Language is often overloaded and context sensitive and a literal
interpretation is often not the right thing to do. C++ is no exception.

'while(true)' in conjunction with break simply means that the standard
loops are not a good fit for the problem (e.g. loop and a half).
 
F

Francesco S. Carta

No, you haven't.

I'm pretty sure that James was kidding up there. This issue and all
common argumentations about it are so obvious and straightforward that
it's hard to believe otherwise :)
 
J

Johannes Schaub (litb)

Alexander said:
In my code I usually find it much simpler to use a while(true) (or
do ... while(true)) loop instead of putting a real condition, and make
a test inside the body of the loop. Usually I find it much more
comfortable to check manually.

So, if you were reading my code, would you dislike this?

Yes i would dislike it, because the proper thing to do is for(;;).
Otherwise, i don't oppose that style of writing, as long as it makes things
easier. If it's just for the sake of it, i oppose. Like with everything.
Let's move on, people...
 
F

Francesco S. Carta

on 20/08/2010 20:17:51 said:
Yes i would dislike it, because the proper thing to do is for(;;).
Otherwise, i don't oppose that style of writing, as long as it makes things
easier. If it's just for the sake of it, i oppose. Like with everything.
Let's move on, people...

Well, it's hard to accept these two statements in the same paragraph:
"Let's move on" and "the proper thing to do is for(;;)"... why should
"while(true)" be improper? That should be just matter of tastes,
shouldn't it? OK, let's move on ;-)

I prefer "for(;;)" too - if nothing less, for it saves keystrokes ;-)

(no, there is no syntax error in that last statement, a pun, maybe...)
 
G

Goran

In my code I usually find it much simpler to use a while(true) (or
do ... while(true)) loop instead of putting a real condition, and make
a test inside the body of the loop. Usually I find it much more
comfortable to check manually.

So, if you were reading my code, would you dislike this?

Meh. Not particularly, but:

* that doesn't save you anything (or, if it does, show the code that
shows how)
* it's misleading.

Goran.
 
J

James Kanze

Well, it always is a lie - such a promise can't ever be proved as
fulfilled ;-)

Yes:). In fact, of course, anything we say about a program (in
the code), is contingent on many external conditions: that the
system doesn't crash, that no one unplugs the machine, etc. But
this is (or should be) understood. For that matter, in most
contexts, "while (true)" admits that the loop may be broken by
means of an assertion failure, or even an exception. It's just
a statement about normal program flow.
 
J

James Kanze

On 2010-08-20 18:42, James Kanze wrote:
No, you haven't. It's almost always used in conjunction with break (real
infinite loops are quite rare).

First real infinite loops aren't that rare; they occur more
often than you'd suspect. And second, using break later in the
loop, rather than stating the conditions up front, at the top,
is obfuscation.
This pattern is so common that that Qt has a special keyword
'forever'.
Language is often overloaded and context sensitive and a literal
interpretation is often not the right thing to do. C++ is no exception.
'while(true)' in conjunction with break simply means that the
standard loops are not a good fit for the problem (e.g. loop
and a half).

Or rather that the programmer doesn't give a shit about good
design and clean programming. Or the people who will have to
clean up his mess afterwards.
 
J

James Kanze

I'm pretty sure that James was kidding up there. This issue and all
common argumentations about it are so obvious and straightforward that
it's hard to believe otherwise :)

I'm certainly not kidding. I believe in writing clean, easily
understood code. Using break in the middle of a loop is not
clean, easily understood code. It's forbidden anywhere I have
an influence over the coding standard.
 
F

Francesco S. Carta

I'm certainly not kidding. I believe in writing clean, easily
understood code. Using break in the middle of a loop is not
clean, easily understood code. It's forbidden anywhere I have
an influence over the coding standard.

Heck, it was almost impossible to understand _that_ from your original
sentence.

Nobody in his sane mind should write a "for(;;)" or "while(true)" loop
meaning it as a "pseudo-truly infinite loop" (I mean, without any
"break", "return" or similar within the loop itself), because the only
way to exit that loop once the program starts executing it would be to
kill the program itself by some external mean - blowing up the machine,
for instance ;-)
 
A

Alf P. Steinbach /Usenet

* James Kanze, on 21.08.2010 16:55:
I'm certainly not kidding. I believe in writing clean, easily
understood code. Using break in the middle of a loop is not
clean, easily understood code. It's forbidden anywhere I have
an influence over the coding standard.

Then you get contortions & redundancy for common loop-and-a-half loops.

There are two arguments against 'while(true)' as opposed to 'for(;;)':

* more to write, and

* causes sillywarnings with MSVC. :)

I think we had the discussion about loop-and-a-half at least twice before, and
you've been partially convinced by some example like

for( ;; )
{
showGameState();
cmd = usersCommand();
if( cmd == exitCmd ) { break; }
doCommand( cmd );
}

Of course you can create monstrosity like showGameStateAndGetUsersCommand and
call that in a 'while' loop head as checking expression with side effects.

Or you can put a call to showGameState() before the loop, which is redundancy,
and move the call in the loop to the bottom, which makes the loop body have a
sequence that is not the sequence of events in one round of interaction.

But hey. :)


Cheers,

- Alf
 
Ö

Öö Tiib

* James Kanze, on 21.08.2010 16:55:





Then you get contortions & redundancy for common loop-and-a-half loops.

There are two arguments against 'while(true)' as opposed to 'for(;;)':

   * more to write, and

   * causes sillywarnings with MSVC. :)

I think we had the discussion about loop-and-a-half at least twice before, and
you've been partially convinced by some example like

   for( ;; )
   {
       showGameState();
       cmd = usersCommand();
       if( cmd == exitCmd ) { break; }
       doCommand( cmd );
   }


Why not:

Command cmd = restCmd; // or where is that cmd declared?
while( cmd != exitCmd )
{
showGameState();
cmd = usersCommand();
doCommand( cmd );
}

Probably i need to read your previous discussions how these
monstrosities like showGameStateAndGetUsersCommand() did enter the
picture.
 
P

Pavel

Öö Tiib said:
Why not:

Command cmd = restCmd; // or where is that cmd declared?
while( cmd != exitCmd )
{
showGameState();
cmd = usersCommand();
doCommand( cmd );
}
I guess because it's not equivalent: your code would doCommand() even if
cmd == exitCmd and Francesco's code wouldn't;

-Pavel
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,902
Latest member
Elena68X5

Latest Threads

Top