Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > main without a return statement

Reply
Thread Tools

main without a return statement

 
 
Charlie Gordon
Guest
Posts: n/a
 
      11-09-2007
"Richard Heathfield" <(E-Mail Removed)> a écrit dans le message de news:
http://www.velocityreviews.com/forums/(E-Mail Removed)...
> Keith Thompson said:
>
>> "Charlie Gordon" <(E-Mail Removed)> writes:
>> [...]
>>> TRUE is not really needed, nor welcome, the classic idiom for this kind
>>> of loop is
>>>
>>> for (; { ... }

>>
>> Or:
>>
>> while (1) { ... }
>>
>> (Let's not have a lengthy debate about which one is clearer, better,
>> and/or more idiomatic, ok?)


Funny, I did not receive Keith's post. Let's feed the troll:

``for (; { ... }'' is unmistakably a testless loop (which you might find
tastless too

``while (1) { ... }'' can be confused with ``while (l) { ... }'', especially
on Usenet. I would use neither of these.

> We can make it a very short debate. My vote is "neither".


Thank you for your constructive criticism, do you mean you use neither of
them, or both, or one but want to keep you preference to yourself ?

--
Chqrlie.


 
Reply With Quote
 
 
 
 
Philip Potter
Guest
Posts: n/a
 
      11-09-2007
Charlie Gordon wrote:
> "Richard Heathfield" <(E-Mail Removed)> a écrit dans le message de news:
>> Keith Thompson said:
>>> "Charlie Gordon" <(E-Mail Removed)> writes:
>>>> TRUE is not really needed, nor welcome, the classic idiom for this kind
>>>> of loop is
>>>>
>>>> for (; { ... }
>>> Or:
>>>
>>> while (1) { ... }
>>>
>>> (Let's not have a lengthy debate about which one is clearer, better,
>>> and/or more idiomatic, ok?)

>
> Funny, I did not receive Keith's post. Let's feed the troll:
>
> ``for (; { ... }'' is unmistakably a testless loop (which you might find
> tastless too
>
> ``while (1) { ... }'' can be confused with ``while (l) { ... }'', especially
> on Usenet. I would use neither of these.


forever:

/* ... */

goto forever;

is clear, concise, doesn't confuse you with a construct which is
normally used for finite loops, and is self-documenting. I can't see
anything at all wrong with it.

Phil

--
Philip Potter pgp <at> doc.ic.ac.uk
 
Reply With Quote
 
 
 
 
Richard Heathfield
Guest
Posts: n/a
 
      11-09-2007
Charlie Gordon said:

<snip>

> Funny, I did not receive Keith's post. Let's feed the troll:
>
> ``for (; { ... }'' is unmistakably a testless loop (which you might
> find tastless too
>
> ``while (1) { ... }'' can be confused with ``while (l) { ... }'',


That took me a while to spot. Or possibly a for.

> especially
> on Usenet. I would use neither of these.
>
>> We can make it a very short debate. My vote is "neither".

>
> Thank you for your constructive criticism,


You're welcome.

> do you mean you use neither of
> them, or both, or one but want to keep you preference to yourself ?


YES!

Actually, my preference is well-documented here in comp.lang.c, and it's
simply stated: if the program ever terminates whilst power is still
available to keep it running, the "infinite loop" construct is a lie that
should not be told. If it truly does not terminate, though, then my choice
would be the for(; version, since compilers are less likely to offer a
warning about a constant condition.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
 
Reply With Quote
 
Charlie Gordon
Guest
Posts: n/a
 
      11-09-2007
"Richard Heathfield" <(E-Mail Removed)> a écrit dans le message de news:
(E-Mail Removed)...
> Charlie Gordon said:
>
> <snip>
>
>> Funny, I did not receive Keith's post. Let's feed the troll:
>>
>> ``for (; { ... }'' is unmistakably a testless loop (which you might
>> find tasteless too
>>
>> ``while (1) { ... }'' can be confused with ``while (l) { ... }'',

>
> That took me a while to spot. Or possibly a for.
>
>> especially
>> on Usenet. I would use neither of these.
>>
>>> We can make it a very short debate. My vote is "neither".

>>
>> Thank you for your constructive criticism,

>
> You're welcome.
>
>> do you mean you use neither of
>> them, or both, or one but want to keep you preference to yourself ?

>
> YES!
>
> Actually, my preference is well-documented here in comp.lang.c, and it's
> simply stated: if the program ever terminates whilst power is still
> available to keep it running, the "infinite loop" construct is a lie that
> should not be told. If it truly does not terminate, though, then my choice
> would be the for(; version, since compilers are less likely to offer a
> warning about a constant condition.


Yes!
I did not call those endless loops, but testless
And as such, there should be *no* test. hence ``for (; { ... }''.

--
Chqrlie.


 
Reply With Quote
 
Charlie Gordon
Guest
Posts: n/a
 
      11-09-2007
"Philip Potter" <(E-Mail Removed)> a écrit dans le message de news:
fh1kev$416$(E-Mail Removed)...
> Charlie Gordon wrote:
>> "Richard Heathfield" <(E-Mail Removed)> a écrit dans le message de
>> news:
>>> Keith Thompson said:
>>>> "Charlie Gordon" <(E-Mail Removed)> writes:
>>>>> TRUE is not really needed, nor welcome, the classic idiom for this
>>>>> kind
>>>>> of loop is
>>>>>
>>>>> for (; { ... }
>>>> Or:
>>>>
>>>> while (1) { ... }
>>>>
>>>> (Let's not have a lengthy debate about which one is clearer, better,
>>>> and/or more idiomatic, ok?)

>>
>> Funny, I did not receive Keith's post. Let's feed the troll:
>>
>> ``for (; { ... }'' is unmistakably a testless loop (which you might
>> find tastless too
>>
>> ``while (1) { ... }'' can be confused with ``while (l) { ... }'',
>> especially on Usenet. I would use neither of these.

>
> forever:
>
> /* ... */
>
> goto forever;
>
> is clear, concise, doesn't confuse you with a construct which is normally
> used for finite loops, and is self-documenting. I can't see anything at
> all wrong with it.


Surely you're joking Mr Potter !

You cannot have more than one of these in a given function, you cannot
'break' from them or 'continue'...

--
Chqrlie.


 
Reply With Quote
 
Philip Potter
Guest
Posts: n/a
 
      11-09-2007
Charlie Gordon wrote:
> "Philip Potter" <(E-Mail Removed)> a écrit dans le message de news:
>> goto forever;
>>
>> is clear, concise, doesn't confuse you with a construct which is normally
>> used for finite loops, and is self-documenting. I can't see anything at
>> all wrong with it.

>
> Surely you're joking Mr Potter !


"Satiring" may be closer to the mark

> You cannot have more than one of these in a given function, you cannot
> 'break' from them or 'continue'...


Why would you ever need more than one loop forever in a given function?
If one loops forever, then the other is unreachable.

"break" merely hides the break condition somewhere else than where you
expect to find it. If you need a loop to terminate, don't use a loop
forever construct.

And "continue" is trivial: 'goto forever;'

--
Philip Potter pgp <at> doc.ic.ac.uk
 
Reply With Quote
 
Charlie Gordon
Guest
Posts: n/a
 
      11-09-2007
"Philip Potter" <(E-Mail Removed)> a écrit dans le message de news:
fh1qdr$phb$(E-Mail Removed)...
> Charlie Gordon wrote:
>> "Philip Potter" <(E-Mail Removed)> a écrit dans le message de news:
>>> goto forever;
>>>
>>> is clear, concise, doesn't confuse you with a construct which is
>>> normally used for finite loops, and is self-documenting. I can't see
>>> anything at all wrong with it.

>>
>> Surely you're joking Mr Potter !

>
> "Satiring" may be closer to the mark


Of course, so was I.

>> You cannot have more than one of these in a given function, you cannot
>> 'break' from them or 'continue'...

>
> Why would you ever need more than one loop forever in a given function? If
> one loops forever, then the other is unreachable.


some forever loops are merely loops for which the break conditions cannot be
conveniently moved to the top. Adding extra booleans with silly names such
as ``done'' or ``working'' is not too elegant.

> "break" merely hides the break condition somewhere else than where you
> expect to find it. If you need a loop to terminate, don't use a loop
> forever construct.


I disagree with this: you could test for abnormal conditions in different
parts of your main daemon loop, and break appropriately and conveniently.
Adding extra logic for this would be cumbersome.

> And "continue" is trivial: 'goto forever;'


sounds more like goto fever

--
Chqrlie.


 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      11-09-2007
Richard Heathfield wrote:
> Charlie Gordon said:
>
> <snip>
>
>> Funny, I did not receive Keith's post. Let's feed the troll:
>>
>> ``for (; { ... }'' is unmistakably a testless loop (which you
>> might find tastless too
>>
>> ``while (1) { ... }'' can be confused with
>> ``while (l) { ... }'',

>
> That took me a while to spot. Or possibly a for.


Do you mean you have found some difference between the two
statements? I confess I do not see any such. Unless he is using
one and ell, which have the same resolution on my screen.

Aha - I tried it on a hex editor.

--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.



--
Posted via a free Usenet account from http://www.teranews.com

 
Reply With Quote
 
jameskuyper@verizon.net
Guest
Posts: n/a
 
      11-09-2007

Charlie Gordon wrote:
> "Philip Potter" <(E-Mail Removed)> a écrit dans le message de news:
> fh1qdr$phb$(E-Mail Removed)...
> > Charlie Gordon wrote:
> >> "Philip Potter" <(E-Mail Removed)> a écrit dans le message de news:

....
> > Why would you ever need more than one loop forever in a given function? If
> > one loops forever, then the other is unreachable.

>
> some forever loops are merely loops for which the break conditions cannot be
> conveniently moved to the top. Adding extra booleans with silly names such
> as ``done'' or ``working'' is not too elegant.


I agree; there's almost always a more elegant way to put the loop
condition where it belongs, in the loop construct. One technique that
often works in otherwise intractable cases is to move some or all of
the loop into a separate subroutine whose return value is a key
component of the loop condition. However, even if you are reduced to
having to use booleans, that still creates code that is easier to
understand than code which hides the main method of exiting the loop
inside the loop.

> > "break" merely hides the break condition somewhere else than where you
> > expect to find it. If you need a loop to terminate, don't use a loop
> > forever construct.

>
> I disagree with this: you could test for abnormal conditions in different
> parts of your main daemon loop, and break appropriately and conveniently.
> Adding extra logic for this would be cumbersome.


I'm not opposed to breaking out of a loop for unusual cases, but the
normal way to exit a loop should involve the loop construct itself;
anything else makes it harder to understand what the loop is actually
doing.

 
Reply With Quote
 
Charlie Gordon
Guest
Posts: n/a
 
      11-10-2007
"CBFalconer" <(E-Mail Removed)> a écrit dans le message de news:
(E-Mail Removed)...
> Richard Heathfield wrote:
>> Charlie Gordon said:
>>
>> <snip>
>>
>>> Funny, I did not receive Keith's post. Let's feed the troll:
>>>
>>> ``for (; { ... }'' is unmistakably a testless loop (which you
>>> might find tastless too
>>>
>>> ``while (1) { ... }'' can be confused with
>>> ``while (l) { ... }'',

>>
>> That took me a while to spot. Or possibly a for.

>
> Do you mean you have found some difference between the two
> statements? I confess I do not see any such. Unless he is using
> one and ell, which have the same resolution on my screen.
>
> Aha - I tried it on a hex editor.


QED

--
Chqrlie.


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
without declare parameter [double square(parameter)] return 0 in main WanHongbin@gmail.com C Programming 5 10-01-2008 03:31 AM
int main(void) { return main(); } Army1987 C Programming 37 04-03-2007 06:45 AM
getting return value from function without return statement. Seong-Kook Shin C Programming 1 06-18-2004 08:19 AM
How do I return a return-code from main? wl Java 2 03-05-2004 05:15 PM



Advertisments