while (1) vs. for ( ;; )

[Michael B Allen]

Should there be any preference between the following logically equivalent
statements?

while (1) {

vs.

for ( ;; ) {

I suspect the answer is "no" but I'd like to know what the consensus is
so that it doesn't blink through my mind anymore when I type it.

Mike

[caduardo21]

You're right. The answer is no. They'll both do the exact same thing.

[Walter Roberson]

In article <pa****************************@ioplex.com>,
Michael B Allen <mb*****@ioplex.com> wrote:

Should there be any preference between the following logically equivalent
statements? while (1) { vs. for ( ;; ) { I suspect the answer is "no" but I'd like to know what the consensus is
so that it doesn't blink through my mind anymore when I type it.

Just my opinion, but I would tend to use them in slightly different
contexts.

I would tend to use while(1) when I was looping for something that
will occur at an indeterminate future time, such as EOF or an
alarm signal.

I would tend to use for(;;) when I was looping for something that
will occur within a bounded time, but which is inconvenient to
express through loop control variables, such as iterating through
a set of data structures until a certain property is detected.

To give it a different slant: for(;;) conveys "iteration", whereas
while(1) conveys "repetition" that is not necessarily iterative.

But as the two work out the same in the end, the choice amounts
to no more than a hint to a human reader.
--
Daylight is a trademark of OSRAM SYLVANIA INC.

[Guillaume]

Question of style, nothing else.
Personally, I tend to prefer 'for (;;)', but that's just my style.

It's like asking which is better:

if () {
}

or:

if ()
{
}

I use the second form exclusively for various reasons, but it's a matter
of style. Doesn't change the code one bit.

[Robert Gamble]

Michael B Allen wrote:

Should there be any preference between the following logically equivalent
statements?

while (1) {

vs.

for ( ;; ) {

I suspect the answer is "no" but I'd like to know what the consensus is
so that it doesn't blink through my mind anymore when I type it.

Many consider the latter preferable, it can be read as "for-ever" and
makes the intention of the programmer clearer. "while" implies a
predicate which may not always be true whereas "for" does not.

Robert Gamble

[Chris McDonald]

Michael B Allen <mb*****@ioplex.com> writes:

Should there be any preference between the following logically equivalent
statements? while (1) {
vs.
for ( ;; ) { I suspect the answer is "no" but I'd like to know what the consensus is
so that it doesn't blink through my mind anymore when I type it.

Preference? Why not move on to something whose intention is clear:

while(true) {

--
Chris.

[Ben Pfaff]

Chris McDonald <ch***@csse.uwa.edu.au> writes:

Michael B Allen <mb*****@ioplex.com> writes:

Should there be any preference between the following logically equivalent
statements?

while (1) {
vs.
for ( ;; ) {

I suspect the answer is "no" but I'd like to know what the consensus is
so that it doesn't blink through my mind anymore when I type it.

Preference? Why not move on to something whose intention is clear:

while(true) {

In what way are the former two statements' intentions not clear?
Both of them obviously loop "forever".
--
A competent C programmer knows how to write C programs correctly,
a C expert knows enough to argue with Dan Pop, and a C expert
expert knows not to bother.

[pete]

Michael B Allen wrote:

Should there be any preference between the following logically equivalent
statements?

while (1) {

vs.

for ( ;; ) {

I suspect the answer is "no" but I'd
like to know what the consensus is
so that it doesn't blink through my mind anymore when I type it.

while(1) gets a warning on my compiler.
for(;;) doesn't.

--
pete

[Chris McDonald]

Ben Pfaff <bl*@cs.stanford.edu> writes:

Chris McDonald <ch***@csse.uwa.edu.au> writes:

Michael B Allen <mb*****@ioplex.com> writes:

Should there be any preference between the following logically equivalent
statements?

while (1) {
vs.
for ( ;; ) {

I suspect the answer is "no" but I'd like to know what the consensus is
so that it doesn't blink through my mind anymore when I type it.

Preference? Why not move on to something whose intention is clear:

while(true) {

In what way are the former two statements' intentions not clear?
Both of them obviously loop "forever".

I would suggest that both while(1) and for(;;) are potentially unclear
to a person (undergrad. student) seeing C for the first time
(while assuming they haven't seen Java or C++, either).

OK, I suggest that while(true) is *clearer*.

--
Chris.

[Keith Thompson]

Chris McDonald <ch***@csse.uwa.edu.au> writes:
[...]

I would suggest that both while(1) and for(;;) are potentially unclear
to a person (undergrad. student) seeing C for the first time
(while assuming they haven't seen Java or C++, either).

I would suggest that anyone who doesn't understand while(1) or for(;;)
isn't going to have much chance of understanding what follows it.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Chris McDonald]

Keith Thompson <ks***@mib.org> writes:

Chris McDonald <ch***@csse.uwa.edu.au> writes:
[...]

I would suggest that both while(1) and for(;;) are potentially unclear
to a person (undergrad. student) seeing C for the first time
(while assuming they haven't seen Java or C++, either).

I would suggest that anyone who doesn't understand while(1) or for(;;)
isn't going to have much chance of understanding what follows it.

I'm sure that everyone reading this newsgroup understands the *role*
of while(1) and for(;;) but, as suggested, consider how a beginner
may read these the first few times.

I believe that it's these little points that can make one textbook a
better introduction than another. It's difficult to argue for the
continued writing of new code that could be written in a clearer fashion.

--
Chris.

[Randy Howard]

Robert Gamble wrote
(in article
<11*********************@f14g2000cwb.googlegroups. com>):

Michael B Allen wrote:

Should there be any preference between the following logically equivalent
statements?

while (1) {

vs.

for ( ;; ) {

I suspect the answer is "no" but I'd like to know what the consensus is
so that it doesn't blink through my mind anymore when I type it.

Many consider the latter preferable, it can be read as "for-ever" and
makes the intention of the programmer clearer. "while" implies a
predicate which may not always be true whereas "for" does not.

This is where Pascal has an advantage. (I probably have some of
the syntax wrong, I haven't written any Pascal since the late
80s)

const hell_freezes_over = false;

repeat
something;
until hell_freezes_over;

Seems to convey the intent quite clearly. :-)

--
Randy Howard (2reply remove FOOBAR)

[Richard Heathfield]

Michael B Allen said:

Should there be any preference between the following logically equivalent
statements?

while (1) {

vs.

for ( ;; ) {

I suspect the answer is "no" but I'd like to know what the consensus is
so that it doesn't blink through my mind anymore when I type it.

while(1) will be flagged by many compilers as "conditional expression is
constant" or some such wording, whereas for(;;) will not be. Consequently,
for(;;) is preferable out of these two choices.

Personally, I prefer neither choice! I would rather have the loop control
statement explicitly document the exit condition (unless there genuinely
isn't one, such as might be the case in an electronic appliance like a
microwave oven, where "forever" can roughly be translated as "whilst power
is being supplied to the appliance").
--
Richard Heathfield
"Usenet is a strange place" - dmr 29 July 1999
http://www.cpax.org.uk
Email rjh at the above domain

[Christian Bau]

In article <43***********@mindspring.com>,
pete <pf*****@mindspring.com> wrote:

Michael B Allen wrote:

Should there be any preference between the following logically equivalent
statements?

while (1) {

vs.

for ( ;; ) {

I suspect the answer is "no" but I'd
like to know what the consensus is
so that it doesn't blink through my mind anymore when I type it.

while(1) gets a warning on my compiler.
for(;;) doesn't.

Could you tell us which compiler? And could you check what it thinks
about

do {
...
} while (0);

?

[akarl]

Randy Howard wrote:

Robert Gamble wrote
(in article
<11*********************@f14g2000cwb.googlegroups. com>):

Michael B Allen wrote:

Should there be any preference between the following logically equivalent
statements?

while (1) {

vs.

for ( ;; ) {

I suspect the answer is "no" but I'd like to know what the consensus is
so that it doesn't blink through my mind anymore when I type it.

Many consider the latter preferable, it can be read as "for-ever" and
makes the intention of the programmer clearer. "while" implies a
predicate which may not always be true whereas "for" does not.

This is where Pascal has an advantage. (I probably have some of
the syntax wrong, I haven't written any Pascal since the late
80s)

const hell_freezes_over = false;

repeat
something;
until hell_freezes_over;

Seems to convey the intent quite clearly. :-)

Well, in C we have the similar do-while statement. In Modula on the
other hand there is a real exit-in-the-middle loop construct:

LOOP
...
IF someCondition THEN EXIT END;
...
END
August

[pete]

Christian Bau wrote:

In article <43***********@mindspring.com>,
pete <pf*****@mindspring.com> wrote:

Michael B Allen wrote:

Should there be any preference
between the following logically equivalent
statements?

while (1) {

vs.

for ( ;; ) {

I suspect the answer is "no" but I'd
like to know what the consensus is
so that it doesn't blink through my mind anymore when I type it.

while(1) gets a warning on my compiler.
for(;;) doesn't.

Could you tell us which compiler? And could you check what it thinks
about

do {
...
} while (0);

It doesn't like that one either.

--
pete

[Guillaume]

Randy Howard wrote:

const hell_freezes_over = false;

repeat
something;
until hell_freezes_over;

Seems to convey the intent quite clearly. :-)

That is, if hell means anything to you. If it doesn't, then it does not
convey much. ;-)

[Richard Tobin]

In article <de**********@enyo.uwa.edu.au>,
Chris McDonald <ch***@csse.uwa.edu.au> wrote:

I'm sure that everyone reading this newsgroup understands the *role*
of while(1) and for(;;) but, as suggested, consider how a beginner
may read these the first few times.

If you're writing code for beginners to read you may well come to
different conclusions from those where you're writing a program to be
maintained by experienced programmers.

-- Richard

[Anton Petrusevich]

Chris McDonald wrote:

I would suggest that both while(1) and for(;;) are potentially unclear
to a person (undergrad. student) seeing C for the first time
(while assuming they haven't seen Java or C++, either).

What about following?
#defined loop_forever for(;;)
--
Anton Petrusevich

[Anton Petrusevich]

pete wrote:

> while(1) gets a warning on my compiler.
> for(;;) doesn't.

Could you tell us which compiler? And could you check what it thinks
about
do {
...
} while (0);

It doesn't like that one either.

What about following?
while(1 == 1) {
....
}
and
do {
....
} while(1 == 0);
--
Anton Petrusevich

[akarl]

Anton Petrusevich wrote:

Chris McDonald wrote:

I would suggest that both while(1) and for(;;) are potentially unclear
to a person (undergrad. student) seeing C for the first time
(while assuming they haven't seen Java or C++, either).

What about following?
#defined loop_forever for(;;)

Defining a new language with the macro preprocessor is seldom a good idea.

August

[Anton Petrusevich]

akarl wrote:

Chris McDonald wrote: I would suggest that both while(1) and for(;;) are potentially unclear
to a person (undergrad. student) seeing C for the first time
(while assuming they haven't seen Java or C++, either).

What about following?
#define loop_forever for(;;)

Defining a new language with the macro preprocessor is seldom a good idea.

I agree with you, but I was asking Chris McDonald. :)
--
Anton Petrusevich

[Ben Pfaff]

Anton Petrusevich <ca***@att-ltd.biz> writes:

What about following?
#defined loop_forever for(;;)

As long as you want to be "cute":
#define ever ;;
for (ever) { ... }
(I would never use this.)
--
int main(void){char p[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuv wxyz.\
\n",*q="kl BIcNBFr.NKEzjwCIxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+=strchr(p,*q++)-p;if(i>=(int)sizeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}

[Alan Balmer]

On Sun, 28 Aug 2005 21:36:51 -0400, Michael B Allen
<mb*****@ioplex.com> wrote:

Should there be any preference between the following logically equivalent
statements?

while (1) {

vs.

for ( ;; ) {

I suspect the answer is "no" but I'd like to know what the consensus is
so that it doesn't blink through my mind anymore when I type it.

They do exactly the same thing. I use the "for ever" form because some
of the compilers I use give a warning on while(1).
--
Al Balmer
Balmer Consulting
re************************@att.net

[Kenneth Brody]

Walter Roberson wrote:

In article <pa****************************@ioplex.com>,
Michael B Allen <mb*****@ioplex.com> wrote:

Should there be any preference between the following logically equivalent
statements?

while (1) {
vs.
for ( ;; ) {
I typically read them as "while true" and "forever".
I suspect the answer is "no" but I'd like to know what the consensus is
so that it doesn't blink through my mind anymore when I type it.

They are functionally identical, and will possibly generate the same
machine code.
Just my opinion, but I would tend to use them in slightly different
contexts.

I would tend to use while(1) when I was looping for something that
will occur at an indeterminate future time, such as EOF or an
alarm signal.
I typically declare an "int done=0;" and then use "while (!done)" in
such cases. It just reads better to me and allows a "clean" exit from
the loop.
I would tend to use for(;;) when I was looping for something that
will occur within a bounded time, but which is inconvenient to
express through loop control variables, such as iterating through
a set of data structures until a certain property is detected.

To give it a different slant: for(;;) conveys "iteration", whereas
while(1) conveys "repetition" that is not necessarily iterative.

But as the two work out the same in the end, the choice amounts
to no more than a hint to a human reader.

True.

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[Alan Balmer]

On Mon, 29 Aug 2005 08:42:47 +0000 (UTC), Richard Heathfield
<in*****@invalid.invalid> wrote:

Michael B Allen said:

Should there be any preference between the following logically equivalent
statements?

while (1) {

vs.

for ( ;; ) {

I suspect the answer is "no" but I'd like to know what the consensus is
so that it doesn't blink through my mind anymore when I type it.

while(1) will be flagged by many compilers as "conditional expression is
constant" or some such wording, whereas for(;;) will not be. Consequently,
for(;;) is preferable out of these two choices.

Personally, I prefer neither choice! I would rather have the loop control
statement explicitly document the exit condition (unless there genuinely
isn't one, such as might be the case in an electronic appliance like a
microwave oven, where "forever" can roughly be translated as "whilst power
is being supplied to the appliance").

It often happens that there are multiple exit conditions. Is it your
preference to set a "get out" flag for these situations? That's my
preference, though I don't feel strongly about it (and I'm likely to
use multiple function returns, too, when a single return is too
contrived.)
--
Al Balmer
Balmer Consulting
re************************@att.net

[Randy Howard]

Guillaume wrote
(in article <43***********************@news.club-internet.fr>):

Randy Howard wrote:

const hell_freezes_over = false;

repeat
something;
until hell_freezes_over;

Seems to convey the intent quite clearly. :-)

That is, if hell means anything to you. If it doesn't, then it does not
convey much. ;-)

It seems that the expression "when hell freezes over" is not as
widespread as I thought. :-)

--
Randy Howard (2reply remove FOOBAR)

[Richard Heathfield]

Alan Balmer said:

On Mon, 29 Aug 2005 08:42:47 +0000 (UTC), Richard Heathfield
<in*****@invalid.invalid> wrote:

Personally, I prefer neither choice! I would rather have the loop control
statement explicitly document the exit condition (unless there genuinely
isn't one, such as might be the case in an electronic appliance like a
microwave oven, where "forever" can roughly be translated as "whilst power
is being supplied to the appliance").
It often happens that there are multiple exit conditions. Is it your
preference to set a "get out" flag for these situations?

Yes: done = 1;
That's my
preference, though I don't feel strongly about it (and I'm likely to
use multiple function returns, too, when a single return is too
contrived.)

I'm quite unlikely to use multiple returns, although I seem to recall that I
have done so on occasion, when in a tearing hurry.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29 July 1999
http://www.cpax.org.uk
Email rjh at the above domain

[Guillaume]

Randy Howard wrote:

It seems that the expression "when hell freezes over" is not as
widespread as I thought. :-)

Lol, I was just being difficult. ;-)

[pete]

Anton Petrusevich wrote:

pete wrote:

> while(1) gets a warning on my compiler.
> for(;;) doesn't.
Could you tell us which compiler? And could you check what it thinks
about
do {
...
} while (0);

It doesn't like that one either.

What about following?
while(1 == 1) {
...
}
and
do {
...
} while(1 == 0);

My compiler warns about a constant expression being
he condition in a loop.
(1 == 1) and (1 == 0) are both such constant expressions.

--
pete

[Alan Balmer]

On Mon, 29 Aug 2005 18:35:12 +0000 (UTC), Richard Heathfield
<in*****@invalid.invalid> wrote:

Alan Balmer said:

On Mon, 29 Aug 2005 08:42:47 +0000 (UTC), Richard Heathfield
<in*****@invalid.invalid> wrote:

Personally, I prefer neither choice! I would rather have the loop control
statement explicitly document the exit condition (unless there genuinely
isn't one, such as might be the case in an electronic appliance like a
microwave oven, where "forever" can roughly be translated as "whilst power
is being supplied to the appliance").
It often happens that there are multiple exit conditions. Is it your
preference to set a "get out" flag for these situations?

Yes: done = 1;

I've also used a flag with multiple values, when I need to know why
the loop was terminated.

That's my
preference, though I don't feel strongly about it (and I'm likely to
use multiple function returns, too, when a single return is too
contrived.)

I'm quite unlikely to use multiple returns, although I seem to recall that I
have done so on occasion, when in a tearing hurry.

The situation where I'm likely to use multiple returns is for sanity
checks at the beginning of a relatively long function;

if (something_strange_about_the_parameters)
return 0;

<do the real stuff>

return 1;
--
Al Balmer
Balmer Consulting
re************************@att.net

[Kevin Handy]

Chris McDonald wrote:

I suspect the answer is "no" but I'd like to know what the consensus is
so that it doesn't blink through my mind anymore when I type it.

Preference? Why not move on to something whose intention is clear:

while(true) {

Why not use

while(is_the_pope_catholic) {

or

while(does_a_bear_shit_in_the_woods) {

or

while(!does_a_fish_need_a_bicycle) {

these should be just as clear, as long as you define them properly.

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Mark B]

"Kevin Handy" <kt*@srv.net> wrote in message
news:11*************@spool6-east.superfeed.net...

Chris McDonald wrote:

I suspect the answer is "no" but I'd like to know what the consensus is
so that it doesn't blink through my mind anymore when I type it. Preference? Why not move on to something whose intention is clear:
while(true) {

Why not use

<snip> while(does_a_bear_shit_in_the_woods) {

I wouldn't recommend using this example as it is a little ambiguous...
Does this bear live in the woods or does he live at the circus?
There's no telling where he shits.

Mark





;-)

[Mark B]

"Alan Balmer" <al******@att.net> wrote in message
news:n9********************************@4ax.com...

On Mon, 29 Aug 2005 18:35:12 +0000 (UTC), Richard Heathfield
<in*****@invalid.invalid> wrote:

Alan Balmer said:

On Mon, 29 Aug 2005 08:42:47 +0000 (UTC), Richard Heathfield
<in*****@invalid.invalid> wrote:
Personally, I prefer neither choice! I would rather have the loop
control
statement explicitly document the exit condition (unless there genuinely
isn't one, such as might be the case in an electronic appliance like a
microwave oven, where "forever" can roughly be translated as "whilst
power
is being supplied to the appliance").
It often happens that there are multiple exit conditions. Is it your
preference to set a "get out" flag for these situations?

Yes: done = 1;

I've also used a flag with multiple values, when I need to know why
the loop was terminated.

That's my
preference, though I don't feel strongly about it (and I'm likely to
use multiple function returns, too, when a single return is too
contrived.)

I'm quite unlikely to use multiple returns, although I seem to recall that
I
have done so on occasion, when in a tearing hurry.

The situation where I'm likely to use multiple returns is for sanity
checks at the beginning of a relatively long function;
if (something_strange_about_the_parameters)
return 0;
<do the real stuff>
return 1;

I know it's only a trivial example... but why not:

if(nothing_strange_about_the_parameters)
status = call_the_real_function(passing_validated_parameter s);
return status;

The 'relatively long functions' are where the bugs typically breed, no?

Mark

[John Bode]

Randy Howard wrote:

Guillaume wrote
(in article <43***********************@news.club-internet.fr>):

Randy Howard wrote:

const hell_freezes_over = false;

repeat
something;
until hell_freezes_over;

Seems to convey the intent quite clearly. :-)

That is, if hell means anything to you. If it doesn't, then it does not
convey much. ;-)

It seems that the expression "when hell freezes over" is not as
widespread as I thought. :-)

Localization issues crop in the damndest places, don't they ;-)

[Chris McDonald]

Anton Petrusevich <ca***@att-ltd.biz> writes:

akarl wrote:

Chris McDonald wrote: I would suggest that both while(1) and for(;;) are potentially unclear
to a person (undergrad. student) seeing C for the first time
(while assuming they haven't seen Java or C++, either). What about following?
#define loop_forever for(;;)

Defining a new language with the macro preprocessor is seldom a good idea.

I agree with you, but I was asking Chris McDonald. :)

Hi Anton,

I too don't think using the preprocessor that way helps (my) students.
There's a potential that they'll flounder at the first opportunity -
either by not adding the directive themselves, or not having a supplied
(non-standard) header file.

--
Chris.

[Peter Nilsson]

Chris McDonald wrote:

Anton Petrusevich <ca***@att-ltd.biz> writes:

akarl wrote:

> Chris McDonald wrote: I would suggest that both while(1) and for(;;) are potentially unclear
> to a person (undergrad. student) seeing C for the first time
> (while assuming they haven't seen Java or C++, either). What about following?
#define loop_forever for(;;)
Defining a new language with the macro preprocessor is seldom a good idea.

I agree with you, but I was asking Chris McDonald. :)

Hi Anton,

I too don't think using the preprocessor that way helps (my) students.
There's a potential that they'll flounder at the first opportunity -
either by not adding the directive themselves, or not having a supplied
(non-standard) header file.

Then might they not also flounder with while(true) by not supplying the
standard header <stdbool.h>?

--
Peter

[Alan Balmer]

On Mon, 29 Aug 2005 21:53:55 GMT, "Mark B" <so***@localbar.com> wrote:

"Alan Balmer" <al******@att.net> wrote in message
news:n9********************************@4ax.com.. .

On Mon, 29 Aug 2005 18:35:12 +0000 (UTC), Richard Heathfield
<in*****@invalid.invalid> wrote:

Alan Balmer said:
On Mon, 29 Aug 2005 08:42:47 +0000 (UTC), Richard Heathfield
<in*****@invalid.invalid> wrote:
>Personally, I prefer neither choice! I would rather have the loop
>control
>statement explicitly document the exit condition (unless there genuinely
>isn't one, such as might be the case in an electronic appliance like a
>microwave oven, where "forever" can roughly be translated as "whilst
>power
>is being supplied to the appliance").
It often happens that there are multiple exit conditions. Is it your
preference to set a "get out" flag for these situations?
Yes: done = 1; I've also used a flag with multiple values, when I need to know why
the loop was terminated.

That's my
preference, though I don't feel strongly about it (and I'm likely to
use multiple function returns, too, when a single return is too
contrived.)
I'm quite unlikely to use multiple returns, although I seem to recall that
I
have done so on occasion, when in a tearing hurry.

The situation where I'm likely to use multiple returns is for sanity
checks at the beginning of a relatively long function;
if (something_strange_about_the_parameters)
return 0;
<do the real stuff>
return 1;

I know it's only a trivial example... but why not:

if(nothing_strange_about_the_parameters)
status = call_the_real_function(passing_validated_parameter s);
return status;

Only because you then have to chase after call_the_real_function(). On
the initial writing, this would probably be only a few lines below,
but that could change. Hmm... Actually, the more I think about it, the
less I like it. Each function turns into two, and the validation's
connection to the rest of the code is more tenuous than necessary. You
could impose a convention, I suppose - every function foo() has a
corresponding function validate_foo(). Even then, you have two
functions which need to be synchronized, a bad maintenance situation.
All in all, I think I prefer the single function with two returns. I
just find it silly to have a couple of lines in an if, followed by a
hundred lines in the else, just to conform to the "single return"
rule.
The 'relatively long functions' are where the bugs typically breed, no?

I suppose, but I miss the relevance.
--
Al Balmer
Balmer Consulting
re************************@att.net

[websnarf]

pete wrote:

Anton Petrusevich wrote:

pete wrote:

> > while(1) gets a warning on my compiler.
> > for(;;) doesn't.
> Could you tell us which compiler? And could you check what it thinks
> about
> do {
> ...
> } while (0);
>
It doesn't like that one either.

What about following?
while(1 == 1) {
...
}
and
do {
...
} while(1 == 0);

My compiler warns about a constant expression being
he condition in a loop.
(1 == 1) and (1 == 0) are both such constant expressions.

Indeed, my experience is that WATCOM C/C++ does not like the do {...}
while(0), PC-Lint does not like while(1) { ... } and most compilers
don't like the 1==1 or 1==0 constant expressions. for(;;) is the one
that wrankles me the most from an intuitive point of view because there
is *no* stated condition, so I don't see why it should be assumed to be
either true or false -- but that's the one which all the compilers and
LINTs I have agree is acceptable.

Personally, I prefer while(1) { ... } just because its explicit about
its intentions right up front, but once you know that for(;;) is
equivalent, its not a big deal to switch using it instead and move on.
(Its not like the a==0 vs 0==a choice in which there is a real issue.)

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[Keith Thompson]

Anton Petrusevich <ca***@att-ltd.biz> writes:

Chris McDonald wrote:

I would suggest that both while(1) and for(;;) are potentially unclear
to a person (undergrad. student) seeing C for the first time
(while assuming they haven't seen Java or C++, either).

What about following?
#defined loop_forever for(;;)

I remember writing either
#define ever ;;
or
#define ever (;;)
when I was in college, but it was a youthful indiscretion.

At the time, I thought it was quite clever. I still think so, but I
no longer think its cleverness was a virtue.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Chris F.A. Johnson]

On 2005-08-29, Kevin Handy wrote:

Chris McDonald wrote:

I suspect the answer is "no" but I'd like to know what the consensus is
so that it doesn't blink through my mind anymore when I type it.

Preference? Why not move on to something whose intention is clear:

while(true) {

Why not use

while(is_the_pope_catholic) {

No, he's not. Did you mean:

while(is_the_pope_Catholic) {
--
Chris F.A. Johnson <http://cfaj.freeshell.org>
================================================== ================
Shell Scripting Recipes: A Problem-Solution Approach, 2005, Apress
<http://www.torfree.net/~chris/books/cfaj/ssr.html>

[Richard Heathfield]

Alan Balmer said:

On Mon, 29 Aug 2005 21:53:55 GMT, "Mark B" <so***@localbar.com> wrote:

[avoiding multiple returns]

I know it's only a trivial example... but why not:

if(nothing_strange_about_the_parameters)
status = call_the_real_function(passing_validated_parameter s);
return status;

Only because you then have to chase after call_the_real_function(). On
the initial writing, this would probably be only a few lines below,
but that could change. Hmm... Actually, the more I think about it, the
less I like it. Each function turns into two, and the validation's
connection to the rest of the code is more tenuous than necessary.

That's a reasonable argument. Here's another, which is diametrically
opposed. :-)

There are two tasks here - the validation of parameters, and the task for
which the function was actually written. Now, there may well be times when
you know perfectly well that the parameters are valid, because it's
actually impossible for them not to be valid. And there are times when
you're not sure.

In the cases where you are sure the parameters are okay, you can call the
function directly, avoiding the overhead of the parameter check. (You could
reasonably add assertion checks here, since they cannot possibly fire if
your program is correct.)

When you're not sure, you call the validation function - which either calls
the "do it" function directly or, perhaps slightly more cleanly, returns an
"everything's fine" value, after which you can proceed to call the "do it"
function yourself.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29 July 1999
http://www.cpax.org.uk
Email rjh at the above domain

[akarl]

Mark B wrote:

"Alan Balmer" <al******@att.net> wrote in message

The situation where I'm likely to use multiple returns is for sanity
checks at the beginning of a relatively long function;
if (something_strange_about_the_parameters)
return 0;
<do the real stuff>
return 1;

I know it's only a trivial example... but why not:

if(nothing_strange_about_the_parameters)
status = call_the_real_function(passing_validated_parameter s);
return status;

....or perhaps

if (something_strange_about_the_parameters) {
status = 0;
} else {
<do the real stuff>
status = 1;
}
return status;
August

[Walter Roberson]

In article <df**********@nwrdmz01.dmz.ncs.ea.ibs-infra.bt.com>,
Richard Heathfield <in*****@invalid.invalid> wrote:

There are two tasks here - the validation of parameters, and the task for
which the function was actually written. Now, there may well be times when
you know perfectly well that the parameters are valid, because it's
actually impossible for them not to be valid. And there are times when
you're not sure. In the cases where you are sure the parameters are okay, you can call the
function directly, avoiding the overhead of the parameter check. (You could
reasonably add assertion checks here, since they cannot possibly fire if
your program is correct.) When you're not sure, you call the validation function - which either calls
the "do it" function directly or, perhaps slightly more cleanly, returns an
"everything's fine" value, after which you can proceed to call the "do it"
function yourself.

Unfortunately, most programmers "know" that they don't make mistakes,
and so will go ahead and call the functions directly. They won't
put in the assert()'s, either, as those are "a drain on performance"
and if you know you are calling with valid parameters you don't need them...
--
Feep if you love VT-52's.

[Chris McDonald]

"Peter Nilsson" <ai***@acay.com.au> writes:

Chris McDonald wrote:

Anton Petrusevich <ca***@att-ltd.biz> writes:

>akarl wrote:
>>>> Chris McDonald wrote:

>>>> I would suggest that both while(1) and for(;;) are potentially unclear
>>>> to a person (undergrad. student) seeing C for the first time
>>>> (while assuming they haven't seen Java or C++, either).

>>> What about following?
>>> #define loop_forever for(;;)
>> Defining a new language with the macro preprocessor is seldom a good idea.

>I agree with you, but I was asking Chris McDonald. :)

Hi Anton,

I too don't think using the preprocessor that way helps (my) students.
There's a potential that they'll flounder at the first opportunity -
either by not adding the directive themselves, or not having a supplied
(non-standard) header file.

Then might they not also flounder with while(true) by not supplying the
standard header <stdbool.h>?

I believe that that is far less of a problem;
we encourage students learning C to compile their code with
<ot>
gcc -std=c99 -Wall -Werror -pedantic
</ot>

in the belief that not only will it be more educational, because
it encourages students learning C to track down a greater number of
compile-time errors, but that it may develop better habits.

Not supplying <stdbool.h> in this context is as meaningful as
not supplying <stdio.h> or, to follow a them,
as useful as an ashtray on a motorbike.

--
Chris.

[Old Wolf]

Ben Pfaff wrote:

Anton Petrusevich <ca***@att-ltd.biz> writes:

What about following?
#defined loop_forever for(;;)

As long as you want to be "cute":
#define ever ;;
for (ever) { ... }
(I would never use this.)

puts("I would never use this") ever

[Christopher Benson-Manica]

Richard Heathfield <in*****@invalid.invalid> wrote:

I'm quite unlikely to use multiple returns

Would you suppose that such a view is common in the world of
professional programming? My work experience is still quite limited,
and it's hard to tell ubiquitous programming conventions from
idiosyncratic oddities...

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

[Charlie Gordon]

"Chris McDonald" <ch***@csse.uwa.edu.au> wrote in message
news:de**********@enyo.uwa.edu.au...

Ben Pfaff <bl*@cs.stanford.edu> writes:

I would suggest that both while(1) and for(;;) are potentially unclear
to a person (undergrad. student) seeing C for the first time
(while assuming they haven't seen Java or C++, either).

OK, I suggest that while(true) is *clearer*.

BS

why not use the real clear thing :

WHILE (TRUE) {
}

or even

WHILE (TRUE == TRUE)
BEGIN
...
END

with obvious macro definitions for dummies ;-)

--
Chqrlie.

[Ben Pfaff]

Christopher Benson-Manica <at***@nospam.cyberspace.org> writes:

Richard Heathfield <in*****@invalid.invalid> wrote:

I'm quite unlikely to use multiple returns

Would you suppose that such a view is common in the world of
professional programming?

It is not a view I have seen espoused at the companies where I
have worked.
--
"C has its problems, but a language designed from scratch would have some too,
and we know C's problems."
--Bjarne Stroustrup

[akarl]

Charlie Gordon wrote:

"Chris McDonald" <ch***@csse.uwa.edu.au> wrote in message
news:de**********@enyo.uwa.edu.au...

Ben Pfaff <bl*@cs.stanford.edu> writes:

I would suggest that both while(1) and for(;;) are potentially unclear
to a person (undergrad. student) seeing C for the first time
(while assuming they haven't seen Java or C++, either).

OK, I suggest that while(true) is *clearer*.

BS

why not use the real clear thing :

WHILE (TRUE) {
}

or even

WHILE (TRUE == TRUE)
BEGIN
...
END

with obvious macro definitions for dummies ;-)

In variable and function declarations the virtues of stdbool.h is clear.
Compare

int isThisAPredicate;

and

bool thisMustBeAPredicate;
August