By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,680 Members | 1,475 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,680 IT Pros & Developers. It's quick & easy.

"Continue" usage

P: n/a
mdh
May I ask the group this somewhat non-focused question....having now
seen "continue" used in some of the solutions I have worked on. ( Ex
7-4 solution by Tondo and Gimpel comes to mind)
Is there a good principle/s for the good usage of "continue"...or...do
any of the regular/irregular contributors have a "favorite" way in
which it is particularly useful. Thanks as usual.
Sep 22 '08 #1
Share this Question
Share on Google+
36 Replies


P: n/a
mdh said:
May I ask the group this somewhat non-focused question....having now
seen "continue" used in some of the solutions I have worked on. ( Ex
7-4 solution by Tondo and Gimpel comes to mind)
Is there a good principle/s for the good usage of "continue"...or...do
any of the regular/irregular contributors have a "favorite" way in
which it is particularly useful. Thanks as usual.
Personally, I prefer to reserve it as an indicator that an otherwise empty
loop is intended to be empty:

for(t = s; *s != '\0'; (*s != c) ? *t++ = *s++ : *s++)
{
continue;
}
*t = '\0';

Another reasonable view is that it should be used for quickly dispensing
with exceptional situations encountered in a loop where you don't want to
do any processing on this iteration (but don't want to stop the loop):

while(line_reading_function(&line, &len, fp) != EOF)
{
skipwhite(&line);
if(line[0] == '\0')
{
continue; /* empty line */
}
if(line[0] == '#')
{
continue; /* comment encountered */
}

/* now we can get on with processing "real" lines */
Sep 22 '08 #2

P: n/a
mdh
On Sep 21, 8:39*pm, Richard Heathfield <r...@see.sig.invalidwrote:
mdh said:
May I ask the group
.....having now
seen "continue" used
Is there a good principle/s for the good usage of "continue"...or...do
any of the regular/irregular contributors have a "favorite" way in
which it is particularly useful. *

Personally, I prefer to reserve it as an indicator that an otherwise empty
loop is intended to be empty:

for(t = s; *s != '\0'; (*s != c) ? *t++ = *s++ : *s++)
{
* continue;}

*t = '\0';

Another reasonable view is that it should be used for quickly dispensing
with exceptional situations encountered in a loop where you don't want to
do any processing on this iteration (but don't want to stop the loop):

while(line_reading_function(&line, &len, fp) != EOF)
{
* skipwhite(&line);
* if(line[0] == '\0')
* {
* * continue; /* empty line */
* }
* if(line[0] == '#')
* {
* * continue; /* comment encountered */
* }

* /* now we can get on with processing "real" lines */
* .
*
thanks Richard for those "hooks" to hang that idea on.
Sep 22 '08 #3

P: n/a
mdh wrote:
>
May I ask the group this somewhat non-focused question....having
now seen "continue" used in some of the solutions I have worked
on. ( Ex 7-4 solution by Tondo and Gimpel comes to mind). Is
there a good principle/s for the good usage of "continue" or do
any of the regular/irregular contributors have a "favorite" way
in which it is particularly useful. Thanks as usual.
I primarily use it to indicate an empty statement. It is not
limited to that however. For example:

while ((EOF != (ch = getc(f))) && ('\n' != ch)) continue;

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
Sep 22 '08 #4

P: n/a
CBFalconer said:
mdh wrote:
>>
May I ask the group this somewhat non-focused question....having
now seen "continue" used in some of the solutions I have worked
on. ( Ex 7-4 solution by Tondo and Gimpel comes to mind). Is
there a good principle/s for the good usage of "continue" or do
any of the regular/irregular contributors have a "favorite" way
in which it is particularly useful. Thanks as usual.

I primarily use it to indicate an empty statement. It is not
limited to that however. For example:

while ((EOF != (ch = getc(f))) && ('\n' != ch)) continue;
Your example is fine, but your description is not, because you can't always
use continue to indicate an empty statement - *only* in loop contexts and
*only* where your intent is for the loop to continue from the
loop-continuation portion of the smallest enclosing iteration statement.
For example:

int main(void)
{
continue;
return 0;
}

is a constraint violation requiring a diagnostic message. Furthermore, the
following example illustrates *legal* C where the use of continue to
indicate a null statement gives the wrong code for the job:

#include <stdio.h>

int main(void)
{
int ch;
while((ch = getchar()) != EOF)
{
if(isalpha(ch))
{
if(ch == 'a' || ch == 'e' || ch == 'i' || ch == 'o' || ch == 'u')
{
continue; /* bad idea */
}
else
{
/* consonant-specific processing - non-aeiou */
}
/* letter-specific processing - for all a-z */
}
}
return 0;
}

In this code, vowels will *not* receive letter-specific processing.

So no, using it to indicate an empty statement is not a good idea. Using it
to indicate an empty loop body is obviously fine, however.

--
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
Sep 22 '08 #5

P: n/a
mdh wrote:
May I ask the group this somewhat non-focused question....having now
seen "continue" used in some of the solutions I have worked on. ( Ex
7-4 solution by Tondo and Gimpel comes to mind)
Is there a good principle/s for the good usage of "continue"...or...do
any of the regular/irregular contributors have a "favorite" way in
which it is particularly useful. Thanks as usual.
I have seen `continue` used sensibly [1] so rarely
that I treat any use of it
as a code smell
suggesting
that there is an opportunity
to fix the design
in a way that eliminates any need
to consider continue for that code.

To indicate an empty loop body
I find `{}` perfectly adequate
on those odd occasions
when it is needed.

Mind the gap.

[1] From my POV, natch.

--
'It changed the future .. and it changed us.' /Babylon 5/

Hewlett-Packard Limited registered office: Cain Road, Bracknell,
registered no: 690597 England Berks RG12 1HN

Sep 22 '08 #6

P: n/a
In article <f4******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:
>Your example is fine, but your description is not, because you can't always
use continue to indicate an empty statement - *only* in loop contexts and
*only* where your intent is for the loop to continue from the
loop-continuation portion of the smallest enclosing iteration statement.
Unlike Fortran, where CONTINUE was a no-op, and was often used at the
end of loops because it could reliably be used to hang the line number
on.

-- Richard
--
Please remember to mention me / in tapes you leave behind.
Sep 22 '08 #7

P: n/a
Chris Dollin <ch**********@hp.comwrites:
mdh wrote:
>May I ask the group this somewhat non-focused question....having now
seen "continue" used in some of the solutions I have worked on. ( Ex
7-4 solution by Tondo and Gimpel comes to mind)
Is there a good principle/s for the good usage of "continue"...or...do
any of the regular/irregular contributors have a "favorite" way in
which it is particularly useful. Thanks as usual.

I have seen `continue` used sensibly [1] so rarely
that I treat any use of it
as a code smell
suggesting
that there is an opportunity
to fix the design
in a way that eliminates any need
to consider continue for that code.

To indicate an empty loop body
I find `{}` perfectly adequate
on those odd occasions
when it is needed.

Mind the gap.

[1] From my POV, natch.
Actually it makes perfect sense when you have your gate condition at the
top of the section - far easier to read, understand and maintain in many
cases (not all of course).

while(n--){

if(complexConditionNotMatched(n))
continue; /* not interested. Check the next if there is one. */

/*do processing of things we are interested in*/

}

Now we could invert the test but then we need to scroll down to the end
of the function to be see what else happens after the block. Here we see
that nothing happens at all - we must move to the next element.

Seems clear, maintainable and decent design to me. I fail to see how it
could be construed as "bad" in any shape or form.

Sep 22 '08 #8

P: n/a
mdh wrote:
May I ask the group this somewhat non-focused question....having now
seen "continue" used in some of the solutions I have worked on. ( Ex
7-4 solution by Tondo and Gimpel comes to mind)
Is there a good principle/s for the good usage of "continue"...or...do
any of the regular/irregular contributors have a "favorite" way in
which it is particularly useful. Thanks as usual.
Hi, my name is Eric, and I'm a `continue' abuser. I use
it as a disguised `goto', simply to avoid excessive nesting:

for (...) {
... prepare for a test ...
if (not_applicable)
continue;
... prepare another test ...
if (not_applicable_2)
continue;
... payload ...
}

Inverting the sense of the tests would eliminate my abusive
`continue' statements:

for (...) {
... prepare for a test ...
if (! not_applicable) {
... prepare another test ...
if (! not_applicable_2) {
... payload ...
}
}
}

.... but if there are three or four such tests, as often
happens when you're converting and validating input from
an uncontrolled source, the "payload" -- the real purpose
of the function --
tends to get squee-
zed into short
little lines all
crowded at the right-
hand side and larded
with ugly line bre-
aks.

So although I know in my heart of hearts that I overuse
`continue' and really shouldn't, the way I really shouldn't
drink and smoke and gamble on cockfights, I, er, continue in
my disgusting habit. There, I've admitted my guilty secret.
They say it's the first step to recovery, but only time will
tell.

--
Eric Sosman
es*****@ieee-dot-org.invalid
Sep 22 '08 #9

P: n/a
Richard<rg****@gmail.comwrites:
Chris Dollin <ch**********@hp.comwrites:
>mdh wrote:
>>May I ask the group this somewhat non-focused question....having now
seen "continue" used in some of the solutions I have worked on.
<snip>
>I have seen `continue` used sensibly [1] so rarely
that I treat any use of it
as a code smell
suggesting
that there is an opportunity
to fix the design
<snip>
>[1] From my POV, natch.

Actually it makes perfect sense when you have your gate condition at the
top of the section - far easier to read, understand and maintain in many
cases (not all of course).

while(n--){

if(complexConditionNotMatched(n))
continue; /* not interested. Check the next if there is one. */

/*do processing of things we are interested in*/

}

Now we could invert the test but then we need to scroll down to the end
of the function
You mean "loop" presumably here.
to be see what else happens after the block. Here we see
that nothing happens at all - we must move to the next element.
There is, of course, no need to invert the test though many people
really seem to object to an empty if branch -- an empty else is fine
but an empty if seems to be OTT for most people.

It is unfortunate that your example is already negative because, to my
mind, there is slightly more clarity in:

while (n--) {
if (complexConditionMatched(n)) {
}
}

but that is just an accident of choosing a negative condition to start
with.
Seems clear, maintainable and decent design to me. I fail to see how it
could be construed as "bad" in any shape or form.
Clear and decent yes, but not 100% maintainable because you loose a
place to put code executed at the end of every loop. I honestly don't
know if this matters (I have no metric for maintainability) but people
site less complex matters are being an issue for maintainability so I
will suggest this one.

I almost never use continue but I don't think this is because I want
to write super maintainable code, just that to me the "if in a loop"
form seems to say what I mean more clearly in all the cases that have
come up.

--
Ben.
Sep 22 '08 #10

P: n/a
mdh
On Sep 22, 5:11*am, Eric Sosman <esos...@ieee-dot-org.invalidwrote:
>
* * *Hi, my name is Eric, and I'm a `continue' abuser.

LOL...

Thanks Eric and all who replied. More hooks to hang my ideas on. Much
Appreciated.
Sep 22 '08 #11

P: n/a
Richard<rg****@gmail.comwrites:
Ben Bacarisse <be********@bsb.me.ukwrites:
>Richard<rg****@gmail.comwrites:
>>Chris Dollin <ch**********@hp.comwrites:

mdh wrote:

May I ask the group this somewhat non-focused question....having now
seen "continue" used in some of the solutions I have worked on.
<snip>
>>>I have seen `continue` used sensibly [1] so rarely
that I treat any use of it
as a code smell
suggesting
that there is an opportunity
to fix the design
<snip>
>>>[1] From my POV, natch.

Actually it makes perfect sense when you have your gate condition at the
top of the section - far easier to read, understand and maintain in many
cases (not all of course).

while(n--){

if(complexConditionNotMatched(n))
continue; /* not interested. Check the next if there is one. */

/*do processing of things we are interested in*/

}

Now we could invert the test but then we need to scroll down to the end
of the function

You mean "loop" presumably here.

Of course. thanks.
Actually I was too hasty to accept your correction. No. I did not mean
loop. I meant the scope of the if block.

e.g

if(match(n){
something();
}else{
somethingelse();
}

here without the continue "in your face" one must check for the else at
the end when reading the code.

This

if(complexConditionNotMatched(n))
continue; /* not interested. Check the next if there is one. */

something();

is much more explicit and clearer.

Sep 22 '08 #12

P: n/a
Eric Sosman <es*****@ieee-dot-org.invalidwrites:
mdh wrote:
>May I ask the group this somewhat non-focused question....having now
seen "continue" used in some of the solutions I have worked on.
<snip>
Hi, my name is Eric, and I'm a `continue' abuser. I use
it as a disguised `goto', simply to avoid excessive nesting:
<fx:stands up>
Hello, my name is Ben, and *I* abuse break. Ah, it feels so good to
say it out loud!

I never get tempted by continue (see elsethread) but I can't keep my
hands off that lovely break. It is sooooo tempting, when you are all
hot and bothered, tightly bound by a strict loop invariant, just to
slip in little break and be free.

[Serious point: in some ways, break is much worse than continue
because of what happens to the way you think about your loops, but I
find myself using break much more than continue and paying the extra
thinking costs later because I do try to verify the logic of all my
loops.]

--
Ben.
Sep 22 '08 #13

P: n/a
Richard wrote:
Chris Dollin <ch**********@hp.comwrites:
>mdh wrote:
>>May I ask the group this somewhat non-focused question....having now
seen "continue" used in some of the solutions I have worked on. ( Ex
7-4 solution by Tondo and Gimpel comes to mind)
Is there a good principle/s for the good usage of "continue"...or...do
any of the regular/irregular contributors have a "favorite" way in
which it is particularly useful. Thanks as usual.

I have seen `continue` used sensibly [1] so rarely
that I treat any use of it
as a code smell
suggesting
that there is an opportunity
to fix the design
in a way that eliminates any need
to consider continue for that code.

To indicate an empty loop body
I find `{}` perfectly adequate
on those odd occasions
when it is needed.

Mind the gap.

[1] From my POV, natch.

Actually it makes perfect sense when you have your gate condition at the
top of the section - far easier to read, understand and maintain in many
cases (not all of course).

while(n--){

if(complexConditionNotMatched(n))
continue; /* not interested. Check the next if there is one. */

/*do processing of things we are interested in*/

}
This is exactly the kind of example that I find smelly. (Weakly
smelly, but still smelly.)

I would write the utterly obvious:

while (n--)
if (complexConditionMatched(n))
doInterestingThings(n);

(Add layout and braces and inlined function body to taste.)
Now we could invert the test but then we need to scroll down to the end
of the function to be see what else happens after the block.
No, we don't. We just look; functions are not /that/ big, especially
nowadays, and editors are not that feeble, so I'm told.
Seems clear, maintainable and decent design to me. I fail to see how it
could be construed as "bad" in any shape or form.
It's not a clear statement of intent; or, more exactly, it's not as
clear a statement as one could write with similar effort.

--
'It changed the future .. and it changed us.' /Babylon 5/

Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England

Sep 22 '08 #14

P: n/a
On 22 Sep, 14:02, Ben Bacarisse <ben.use...@bsb.me.ukwrote:
Eric Sosman <esos...@ieee-dot-org.invalidwrites:
mdh wrote:
May I ask the group this somewhat non-focused question....having now
seen "continue" used in some of the solutions I have worked on.
<snip>
Hi, my name is Eric, and I'm a `continue' abuser. I use
it as a disguised `goto', simply to avoid excessive nesting:

<fx:stands up>
Hello, my name is Ben, and *I* abuse break. Ah, it feels so good to
say it out loud!

I never get tempted by continue (see elsethread) but I can't keep my
hands off that lovely break. It is sooooo tempting, when you are all
hot and bothered, tightly bound by a strict loop invariant, just to
slip in little break and be free.

[Serious point: in some ways, break is much worse than continue
because of what happens to the way you think about your loops, but I
find myself using break much more than continue and paying the extra
thinking costs later because I do try to verify the logic of all my
loops.]
I too am an inveterate break user and hardly ever use continue.
I think my continue is about the same as my goto usage.

As you say though break is potentially much worse. I think the
temptation to use it is because it it actually provides a useful
construct. continue seems to add confuscation without any particular
gain.

while (next_item() != end)
{
if (!match())
continue;

process_item();
}

seems less clear than

while (next_item() != end)
{
if (match())
process_item();
}
whilst I sometimes stuctures like this handy (and clear)

for (;;)
{
pre_process();
if (!more())
break;
post_process();
}
--
Nick Keighley
Sep 22 '08 #15

P: n/a
Chris Dollin <ch**********@hp.comwrites:
Richard wrote:
>Chris Dollin <ch**********@hp.comwrites:
>>mdh wrote:

May I ask the group this somewhat non-focused question....having now
seen "continue" used in some of the solutions I have worked on. ( Ex
7-4 solution by Tondo and Gimpel comes to mind)
Is there a good principle/s for the good usage of "continue"...or...do
any of the regular/irregular contributors have a "favorite" way in
which it is particularly useful. Thanks as usual.

I have seen `continue` used sensibly [1] so rarely
that I treat any use of it
as a code smell
suggesting
that there is an opportunity
to fix the design
in a way that eliminates any need
to consider continue for that code.

To indicate an empty loop body
I find `{}` perfectly adequate
on those odd occasions
when it is needed.

Mind the gap.

[1] From my POV, natch.

Actually it makes perfect sense when you have your gate condition at the
top of the section - far easier to read, understand and maintain in many
cases (not all of course).

while(n--){

if(complexConditionNotMatched(n))
continue; /* not interested. Check the next if there is one. */

/*do processing of things we are interested in*/

}

This is exactly the kind of example that I find smelly. (Weakly
smelly, but still smelly.)
Wierd. I see the above and it is 100% clear and concise. No scrolling
needed. No guesswork. In fact I can not think of anything better for
this.

>
I would write the utterly obvious:

while (n--)
if (complexConditionMatched(n))
doInterestingThings(n);

(Add layout and braces and inlined function body to taste.)
Of course. And the scroll down to see what, if anything, is on the else
part. Already more complicated.
>
>Now we could invert the test but then we need to scroll down to the end
of the function to be see what else happens after the block.

No, we don't. We just look; functions are not /that/ big, especially
Immaterial. They can be. My way makes it immaterial anyway.
nowadays, and editors are not that feeble, so I'm told.
I guess you are trying to belittle my comments with that?
>
>Seems clear, maintainable and decent design to me. I fail to see how it
could be construed as "bad" in any shape or form.

It's not a clear statement of intent; or, more exactly, it's not as
clear a statement as one could write with similar effort.
It is totally clear.

If I am not interested in this element then check the next one. What
could be easier. I suspect you have made your mind up so any more
discussion will be a waste of time.
Sep 22 '08 #16

P: n/a
Richard wrote:
Chris Dollin <ch**********@hp.comwrites:
>No, we don't. We just look; functions are not /that/ big, especially

Immaterial. They can be. My way makes it immaterial anyway.
If a function is as big as you suggest, you have already lost.
>nowadays, and editors are not that feeble, so I'm told.

I guess you are trying to belittle my comments with that?
Your guesswork is wonky. That's not a statement about you, or
your comments, but about modern programmer's-editors.
>>Seems clear, maintainable and decent design to me. I fail to see how it
could be construed as "bad" in any shape or form.

It's not a clear statement of intent; or, more exactly, it's not as
clear a statement as one could write with similar effort.

It is totally clear.
There's an unnecessary `continue` in it that isn't contributing
to clarity. I expect constructs like `continue` that play with
control flow to pull their weight and not just substitute for
syntactic rearrangements. The power of `continue` is that it
can leap out of nested blocks and conditionals; the price of
`continue` is that you have to track down what it skips and
where it goes in a way that you don't with the "structured"
constructs. Forcing this on the reader is a load; forcing them
when a straightforward rearrangement makes it unnecessary
and IMAO adds clarity is just ... untidy.
If I am not interested in this element then check the next one. What
could be easier.
if this is interesting, process it

is easier.
I suspect you have made your mind up so any more
discussion will be a waste of time.
Of course I've made my mind up; if you want to convince me
otherwise, you need a better argument that doesn't ignore mine.

--
'It changed the future .. and it changed us.' /Babylon 5/

Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England

Sep 22 '08 #17

P: n/a
Richard wrote:
Once more

while(n--){

if(complexConditionNotMatched(n))
continue; /* not interested. Check the next if there is one. */

/*do processing of things we are interested in*/
}

Has to be easier to comprehend and check than:

while(n--){

if(complexConditionMatched(n)){
/*do processing of things we are interested in*/
}

}
There's no "has to be"; it just /isn't/ easier (for me) than
the intent-displaying code.
because in the second block one MUST go down to check the end of the
function to see what happens for the non matched element.
In your example, I can just see what happens. If you had a whole
mess of code in there, I'd do an Extract Method\\\\\\Function on
it and mutter Dark Words about whoever had written the mess.

--
'It changed the future .. and it changed us.' /Babylon 5/

Hewlett-Packard Limited registered office: Cain Road, Bracknell,
registered no: 690597 England Berks RG12 1HN

Sep 22 '08 #18

P: n/a
Chris Dollin <ch**********@hp.comwrites:
Richard wrote:
>Chris Dollin <ch**********@hp.comwrites:
>>No, we don't. We just look; functions are not /that/ big, especially

Immaterial. They can be. My way makes it immaterial anyway.

If a function is as big as you suggest, you have already lost.
Do you notice your "if" there? Why are you second guessing what the nex
block is like?
>
>>nowadays, and editors are not that feeble, so I'm told.

I guess you are trying to belittle my comments with that?

Your guesswork is wonky. That's not a statement about you, or
your comments, but about modern programmer's-editors.
I know all about modern editors. But why even bring them up. they are
immaterial to the point in hand.
>
>>>Seems clear, maintainable and decent design to me. I fail to see how it
could be construed as "bad" in any shape or form.

It's not a clear statement of intent; or, more exactly, it's not as
clear a statement as one could write with similar effort.

It is totally clear.

There's an unnecessary `continue` in it that isn't contributing
to clarity.
Says you. I have explained why it is contributing to clarity. What YOU
exect is immateterial here since you are coming from a mindset which
already says use of continue indicates a broken design. I have given a
very simple use of it which is clear, concise and requires less code
browsing to see what happens when an element is not suitable for
processing.

Here, I will show you again:

while(n--){

if(complexConditionNotMatched(n))
continue; /* not interested. Check the next if there is one. */

/*do processing of things we are interested in*/

}

*snip*

Now it obvious to me that you have a thing against continue and no
amount of logical argument will convince you otherwise. The fact that
you are reaching for an editors functionality to make that "extra
browsing" painless is proof in the pudding to me that further
argument/discussion is pointless.

Bottom line is : you think they are bad and are used by poor programmers
to cover up poor design.

I think the above is very well designed and crystal clear.
Sep 22 '08 #19

P: n/a
Richard<rg****@gmail.comwrites:
Ben Bacarisse <be********@bsb.me.ukwrites:
<big snip>

I don't think there are any substantive issues there than this:
>No, there is nothing you can add for clarity. Please don't take the
fact that you may not always able to persuade as being evidence that
your readers don't comprehend.

I do not. But I am a bit bewildered by your arguments here. Nothing you
have said is easier or "more maintainable" (in my mind of course) than
my example which is concise, easy to read and very, very localised
without the need to check for else statements.

Once more

while(n--){

if(complexConditionNotMatched(n))
continue; /* not interested. Check the next if there is one. */

/*do processing of things we are interested in*/
}

Has to be easier to comprehend and check than:

while(n--){

if(complexConditionMatched(n)){
/*do processing of things we are interested in*/
}

}

because in the second block one MUST go down to check the end of the
function to see what happens for the non matched element.
Why are you bringing up "easier to understand" -- I agreed about that
several messages ago?

The only issue I raised was maintainability. Now, I have admitted
that I don't really know what people mean here, but you brought it up
so it must mean something to you. I asked for an example of something
that, in your view impairs maintainability, but you did not offer one.
Without that I will be at a disadvantage, because I don't know what I
mean by it and you haven't said what you mean by it!

Other people seem to hold that code is more maintainable if it can be
modified by making "local changes". I posited a change: add something
that has to be done every time after the loop's (current) body. To do
that, if a loop has a continue, the maintenance programmer has to
check for that and either replace the continue with a goto or re-write
using an if that encloses the (current) body. Neither is what I
understand by a "local change".

This may not be what you mean by maintainability, in which case you
use is (by your criteria) unimpeachable, but it seems to match what I
think other people call maintainability.

Please don't repeat that your code if for cases where this change is
never warranted. If you can code for all future changes you should
write a book to tell the rest of how to do this. If, on the other
hand, you claim that this change is never need in loops that have this
specific pattern, then I'll shut up and just accept you have a much
deeper knowledge of code patterns than I have ever managed to attain
(but you should have brought up the fact that you know this never
happens when you offered the code pattern).

--
Ben.
Sep 22 '08 #20

P: n/a
Chris Dollin <ch**********@hp.comwrites:
Richard wrote:
>Once more

while(n--){

if(complexConditionNotMatched(n))
continue; /* not interested. Check the next if there is one. */

/*do processing of things we are interested in*/
}

Has to be easier to comprehend and check than:

while(n--){

if(complexConditionMatched(n)){
/*do processing of things we are interested in*/
}

}

There's no "has to be"; it just /isn't/ easier (for me) than
the intent-displaying code.
Because you hate continues. The reason it has to be when using metrics
like code length is simple:

its less code

its less to browse

there is no else to worry about

we jump back to start of loop while still visible when debugging.

I can not see one single negative in that code above.

Not one.
>
>because in the second block one MUST go down to check the end of the
function to see what happens for the non matched element.

In your example, I can just see what happens. If you had a whole
mess of code in there, I'd do an Extract Method\\\\\\Function on
it and mutter Dark Words about whoever had written the mess.
I'm quite sure you would. Me? I would say "Oh that first few lines makes
it perfectly clear what elements we are interested in processing and
which not.
Sep 22 '08 #21

P: n/a
Ben Bacarisse <be********@bsb.me.ukwrites:
Richard<rg****@gmail.comwrites:
>Ben Bacarisse <be********@bsb.me.ukwrites:
<big snip>

I don't think there are any substantive issues there than this:
>>No, there is nothing you can add for clarity. Please don't take the
fact that you may not always able to persuade as being evidence that
your readers don't comprehend.

I do not. But I am a bit bewildered by your arguments here. Nothing you
have said is easier or "more maintainable" (in my mind of course) than
my example which is concise, easy to read and very, very localised
without the need to check for else statements.

Once more

while(n--){

if(complexConditionNotMatched(n))
continue; /* not interested. Check the next if there is one. */

/*do processing of things we are interested in*/
}

Has to be easier to comprehend and check than:

while(n--){

if(complexConditionMatched(n)){
/*do processing of things we are interested in*/
}

}

because in the second block one MUST go down to check the end of the
function to see what happens for the non matched element.

Why are you bringing up "easier to understand" -- I agreed about that
several messages ago?

The only issue I raised was maintainability. Now, I have admitted
that I don't really know what people mean here, but you brought it up
so it must mean something to you. I asked for an example of something
that, in your view impairs maintainability, but you did not offer one.
I thought it was obvious from the context. The less code needed to
understand a certain branch the better. That is one aspect of it.
Without that I will be at a disadvantage, because I don't know what I
mean by it and you haven't said what you mean by it!

Other people seem to hold that code is more maintainable if it can be
modified by making "local changes". I posited a change: add something
that has to be done every time after the loop's (current) body. To do
sure. In that case dont use continue : change it to an empty block
followed by an else. Easy enough

while(n--){
if(!cond(n)){
/*do nothing*/
}else{
/*do something*/
}

something to do all the time:
}

Not exactly rocket science.
that, if a loop has a continue, the maintenance programmer has to
check for that and either replace the continue with a goto or re-write
using an if that encloses the (current) body. Neither is what I
understand by a "local change".

This may not be what you mean by maintainability, in which case you
use is (by your criteria) unimpeachable, but it seems to match what I
think other people call maintainability.
Your example is fair and one aspect of it. It means many things to many
people.

But one of the most important is the ability to see what peoples code is
doing at a glance and assuming this code is working as desired I can
only consider that a total nOOb or fool would NOT understand what the
following code does for elements which do not match the criteria for
further processing:
>while(n--){

if(complexConditionNotMatched(n))
continue; /* not interested. Check the next if there is one. */

/*do processing of things we are interested in*/
}
>
Please don't repeat that your code if for cases where this change is
never warranted. If you can code for all future changes you should
write a book to tell the rest of how to do this. If, on the other
Where did I say that? I am merely saying (and as usual in c.l.c it gets
dragged through the bushes backwards) that "continue" is not an
indicator that code is poorly designed in any shape or form.
hand, you claim that this change is never need in loops that have this
specific pattern, then I'll shut up and just accept you have a much
deeper knowledge of code patterns than I have ever managed to attain
(but you should have brought up the fact that you know this never
happens when you offered the code pattern).
I offered the "pattern" for the reasons stated above. I'm sure you dont
mean to sound like you are posturing with your qualifications with that
last statement, but I'm not offering my POV to have a pissing
competition. I think that Chris' original statement about using continue
is ill founded and incorrect and I have offered reasons for it. I dont
know what you mean by "code patterns" in this respect - it seems it just
muddies the waters and takes the conversation into a totally different
realm.

Using "continue" is simply NOT an indicator of a poor design.
Sep 22 '08 #22

P: n/a
Richard wrote:
Chris Dollin <ch**********@hp.comwrites:
>Richard wrote:
>>Chris Dollin <ch**********@hp.comwrites:

No, we don't. We just look; functions are not /that/ big, especially

Immaterial. They can be. My way makes it immaterial anyway.

If a function is as big as you suggest, you have already lost.

Do you notice your "if" there? Why are you second guessing what the nex
block is like?
I'm not. If it's small, there is no problem. If it's big, the
code is -- in general -- /already/ smelly. Fix that first.
>>>nowadays, and editors are not that feeble, so I'm told.

I guess you are trying to belittle my comments with that?

Your guesswork is wonky. That's not a statement about you, or
your comments, but about modern programmer's-editors.

I know all about modern editors. But why even bring them up. they are
immaterial to the point in hand.
Because /you/ were complaining about the overhead of having to scroll
to find the end of the loop and thus that there's no else clause.
I believe this is a non-issue for reasons presented in this thread.
>>>>Seems clear, maintainable and decent design to me. I fail to see how it
could be construed as "bad" in any shape or form.

It's not a clear statement of intent; or, more exactly, it's not as
clear a statement as one could write with similar effort.

It is totally clear.

There's an unnecessary `continue` in it that isn't contributing
to clarity.

Says you. I have explained why it is contributing to clarity.
Yes, I have understood your special-case argument.
What YOU
exect is immateterial here since you are coming from a mindset which
already says use of continue indicates a broken design.
Suggests. (Indicates is too strong.) And not /broken/ -- one that
can be improved.
I have given a
very simple use of it which is clear,
Ish.
concise
Yes.
and requires less code browsing
Unproven.
to see what happens when an element is not suitable for
processing.

Here, I will show you again:
I'm not bloody deaf, nor yet senile. Give over.
Now it obvious to me that you have a thing against continue and no
amount of logical argument will convince you otherwise. The fact that
you are reaching for an editors functionality to make that "extra
browsing" painless is proof in the pudding to me that further
argument/discussion is pointless.
See above.
Bottom line is : you think they are bad and are used by poor programmers
to cover up poor design.
I think they /suggest/ an opportunity for /design improvement/, and
I have nowhere restricted my statements to /poor programmers/. Don't
misrepresent my position, ridicule the misrepresentation, and then
claim to have won the argument. It does not strengthen your position.
I think the above is very well designed and crystal clear.
I think it's an unnecessary complication.

Andy is waving goodbye!

--
'It changed the future .. and it changed us.' /Babylon 5/

Hewlett-Packard Limited Cain Road, Bracknell, registered no:
registered office: Berks RG12 1HN 690597 England

Sep 22 '08 #23

P: n/a
Chris Dollin <ch**********@hp.comwrites:
Richard wrote:
>Chris Dollin <ch**********@hp.comwrites:
>>Richard wrote:

Chris Dollin <ch**********@hp.comwrites:

No, we don't. We just look; functions are not /that/ big, especially

Immaterial. They can be. My way makes it immaterial anyway.

If a function is as big as you suggest, you have already lost.

Do you notice your "if" there? Why are you second guessing what the nex
block is like?

I'm not. If it's small, there is no problem. If it's big, the
code is -- in general -- /already/ smelly. Fix that first.
>>>>nowadays, and editors are not that feeble, so I'm told.

I guess you are trying to belittle my comments with that?

Your guesswork is wonky. That's not a statement about you, or
your comments, but about modern programmer's-editors.

I know all about modern editors. But why even bring them up. they are
immaterial to the point in hand.

Because /you/ were complaining about the overhead of having to scroll
to find the end of the loop and thus that there's no else clause.
I believe this is a non-issue for reasons presented in this thread.
Sigh. In my method there is no question of it anyway. Do you not see
that. I was not "complaining" either. I was merely pointing out there
was no need with the continue. Holy of holies.
>
>>>>>Seems clear, maintainable and decent design to me. I fail to see how it
>could be construed as "bad" in any shape or form.
>
It's not a clear statement of intent; or, more exactly, it's not as
clear a statement as one could write with similar effort.

It is totally clear.

There's an unnecessary `continue` in it that isn't contributing
to clarity.

Says you. I have explained why it is contributing to clarity.

Yes, I have understood your special-case argument.
Special case?

So you acknowledge that this "special case" is not a broken design?

Good. My job is done.
Sep 22 '08 #24

P: n/a
Richard<rg****@gmail.comwrites:
Ben Bacarisse <be********@bsb.me.ukwrites:
>Richard<rg****@gmail.comwrites:
>>Ben Bacarisse <be********@bsb.me.ukwrites:
<big snip>

I don't think there are any substantive issues there than this:
>>>No, there is nothing you can add for clarity. Please don't take the
fact that you may not always able to persuade as being evidence that
your readers don't comprehend.

I do not. But I am a bit bewildered by your arguments here. Nothing you
have said is easier or "more maintainable" (in my mind of course) than
my example which is concise, easy to read and very, very localised
without the need to check for else statements.

Once more

while(n--){

if(complexConditionNotMatched(n))
continue; /* not interested. Check the next if there is one. */

/*do processing of things we are interested in*/
}

Has to be easier to comprehend and check than:

while(n--){

if(complexConditionMatched(n)){
/*do processing of things we are interested in*/
}

}

because in the second block one MUST go down to check the end of the
function to see what happens for the non matched element.

Why are you bringing up "easier to understand" -- I agreed about that
several messages ago?

The only issue I raised was maintainability. Now, I have admitted
that I don't really know what people mean here, but you brought it up
so it must mean something to you. I asked for an example of something
that, in your view impairs maintainability, but you did not offer one.

I thought it was obvious from the context. The less code needed to
understand a certain branch the better. That is one aspect of it.
I thought that was covered by "clarity". Your original claim was that
is was clear and maintainable. If maintainable code just has to be
clear then, I agree, you are done. I think maintainable code has to
be easily alterable, and this sometimes requires more than just
clarity.
>Without that I will be at a disadvantage, because I don't know what I
mean by it and you haven't said what you mean by it!

Other people seem to hold that code is more maintainable if it can be
modified by making "local changes". I posited a change: add something
that has to be done every time after the loop's (current) body. To do

sure. In that case dont use continue : change it to an empty block
followed by an else. Easy enough

while(n--){
if(!cond(n)){
/*do nothing*/
}else{
/*do something*/
}

something to do all the time:
}

Not exactly rocket science.
I know. This is why I wanted you to say what you mean by
maintainable. If code is maintainable despite having to make such
changes, I want to know what you consider to be harmful to
maintainability. Otherwise all code is maintainable (provided it is
clear) and you could have just said "this code is clear" -- implying
that it is therefore (by your definition) maintainable. What, in
addition to clarity, were you claiming by saying it is maintainable?
>that, if a loop has a continue, the maintenance programmer has to
check for that and either replace the continue with a goto or re-write
using an if that encloses the (current) body. Neither is what I
understand by a "local change".

This may not be what you mean by maintainability, in which case you
use is (by your criteria) unimpeachable, but it seems to match what I
think other people call maintainability.

Your example is fair and one aspect of it. It means many things to many
people.
If you said what it means to you, we could avoid going round again.
But one of the most important is the ability to see what peoples code is
doing at a glance and assuming this code is working as desired I can
only consider that a total nOOb or fool would NOT understand what the
following code does for elements which do not match the criteria for
further processing:
>>while(n--){

if(complexConditionNotMatched(n))
continue; /* not interested. Check the next if there is one. */

/*do processing of things we are interested in*/
}
Simply someone who because the loop is long (as you concede is
possible) misses the continue when adding code at the end. I get the
idea from some people that robust maintainable code has to defend
against such simple mistakes. If you don't worry about that, then you
have defined the problem away.
>Please don't repeat that your code if for cases where this change is
never warranted. If you can code for all future changes you should
write a book to tell the rest of how to do this. If, on the other

Where did I say that?
In message-ID: <gb**********@registered.motzarella.org>. When I first
suggest the possibility of having to add such code you said:

| Yes. if you need to. In this case you do not need to. It is very
| clear.

which suggested to me you were discounting a whole bunch future of
changes right form the start.
I am merely saying (and as usual in c.l.c it gets
dragged through the bushes backwards) that "continue" is not an
indicator that code is poorly designed in any shape or form.
>hand, you claim that this change is never need in loops that have this
specific pattern, then I'll shut up and just accept you have a much
deeper knowledge of code patterns than I have ever managed to attain
(but you should have brought up the fact that you know this never
happens when you offered the code pattern).

I offered the "pattern" for the reasons stated above. I'm sure you dont
mean to sound like you are posturing with your qualifications
No. I have no qualifications to posture about. I have always tried
to allow for local changes which, to my mind, rules out your usage of
continue. But you speak as if you have very much greater experience of
software development than I do, so if you tell me that this is not a
problem -- that you'd expect maintenance programmers to spot the
continue and change it if needed -- I have to accept it. I have no
experience to counter your claim. Other people might, but I don't.
with that
last statement, but I'm not offering my POV to have a pissing
competition. I think that Chris' original statement about using continue
is ill founded and incorrect and I have offered reasons for it. I dont
know what you mean by "code patterns" in this respect - it seems it just
muddies the waters and takes the conversation into a totally different
realm.

Using "continue" is simply NOT an indicator of a poor design.
This is a stronger statement than I would make and not, I think, what
Chris was saying (but I should leave him to say). I understood him to
mean it should cause one to go check to see if there was not a better
way and in that respect (if that is what he means) I agree.

--
Ben.
Sep 22 '08 #25

P: n/a
On Mon, 22 Sep 2008 08:11:39 -0400, Eric Sosman
<es*****@ieee-dot-org.invalidwrote:
>mdh wrote:
>May I ask the group this somewhat non-focused question....having now
seen "continue" used in some of the solutions I have worked on. ( Ex
7-4 solution by Tondo and Gimpel comes to mind)
Is there a good principle/s for the good usage of "continue"...or...do
any of the regular/irregular contributors have a "favorite" way in
which it is particularly useful. Thanks as usual.

Hi, my name is Eric, and I'm a `continue' abuser. I use
it as a disguised `goto', simply to avoid excessive nesting:

for (...) {
... prepare for a test ...
if (not_applicable)
continue;
... prepare another test ...
if (not_applicable_2)
continue;
... payload ...
}

Inverting the sense of the tests would eliminate my abusive
`continue' statements:

for (...) {
... prepare for a test ...
if (! not_applicable) {
... prepare another test ...
if (! not_applicable_2) {
... payload ...
}
}
}

... but if there are three or four such tests, as often
happens when you're converting and validating input from
an uncontrolled source, the "payload" -- the real purpose
of the function --
tends to get squee-
zed into short
little lines all
crowded at the right-
hand side and larded
with ugly line bre-
aks.

So although I know in my heart of hearts that I overuse
`continue' and really shouldn't, the way I really shouldn't
drink and smoke and gamble on cockfights, I, er, continue in
my disgusting habit. There, I've admitted my guilty secret.
They say it's the first step to recovery, but only time will
tell.
Speaking as a fellow sinner, I'm with Eric on this one. Unlike
Eric I'm unrepentent - I think it's a case of doing the best one
can with a defective tool.

OT
I look at this as a language design issue. There is a specific
software pattern involved here that I call a filter. We do X if
something passes tests t1, t2, etc. If the tests can be written
as simple boolean expressions then C provides short circuit
evaluation, e.g.,

if(t1 && t2 ...) X

However that doesn't work if there intermediate prep work is
required. There is IMOWINTBQ (In my opinion which is not to be
questioned) a "right" way to do it available in some languages,
the andif construct. The andif blocks can follow if blocks and
other andif blocks - they are short circuit forms at the block
level. Thus we would write:

if (t1) {
... prep work ...
} andif (t2) {
... prep work ...
} andif (t3) {
... payload ...
}

(Use whatever layout floats your boat)

Since C doesn't have an andif or equivalent we have to fake it.
(Deep nesting ifs is not a solution - it is a disease.) Using
continue is a solution of sorts and one that I am comfortable
with but it has its faults. The first is that it must be within
a loop. The second is that to use it you have to invert the
tests. The third is that it is immoral and fattening. Still,
there is no solution in C that is not weird in some way.

/OT
Richard Harter, cr*@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
Save the Earth now!!
It's the only planet with chocolate.
Sep 22 '08 #26

P: n/a
mdh wrote:
On Sep 22, 5:11 am, Eric Sosman <esos...@ieee-dot-org.invalidwrote:
> Hi, my name is Eric, and I'm a `continue' abuser.


LOL...

Thanks Eric and all who replied. More hooks to hang my ideas on. Much
Appreciated.
It occurs to me that I've still not revealed my worst
abuse of `continue'; I have further sins to confess. Having
just returned from a wake and being filled with intimations
of mortality, I hereby unburden my soul:

This particular abuse arose in connection with processing
command-line arguments. I'd loop through the argv[] array and
look up each argument in an array of strings representing the
command-line flags. Then I'd `switch' on the array index to get
to flag-specific processing. Some flags stood alone, some required
a value from a following argument, some of those values got
converted to numbers and range-checked, nothing very surprising.

But every `case' for a flag that gobbled a following value had
to check whether another argument actually existed, lest it run
off the end of the argv[] array. And I wondered: Could I somehow
rearrange things so at least part of the check-for-more code
could be factored out and de-duplicated?

Here, O my brethren, is the pit of sin into which I fell:

for (i = 1; i < argc; ++i) {
id = ... index of argv[i] in flags array ...;
switch (id) {
case 0: /* -x */
x_flag = 1;
continue;
case 1: /* -p path */
if (++i < argc) {
p_path = argv[argc];
continue;
}
break;
case 2: /* -n number */
if (++i < argc) {
n = ... numeric value of argv[i] ...;
if (0 < n && n < 42) {
n_value = n;
continue;
}
}
break;
default:
fprintf (stderr, "\"%s\" is not recognized\n",
argv[i]);
return -1;
}
fprintf (stderr, "Invalid or missing value after %s\n",
flags[id]);
return -1;
}
return 0;

Take heed, sinners: The slope is steep and slippery. It
starts easy, like a few idle puffs of maryjane, but the
descent to crack and smack and horse and worse is easier still.
Abuse `continue' at your peril!

(And, I've still got to admit, at your pleasure.)

--
Eric Sosman
es*****@ieee-dot-org.invalid
Sep 22 '08 #27

P: n/a
Ben Bacarisse wrote:
Richard<rg****@gmail.comwrites:
.... snip ...
>
>while (n--) {
if (!cond(n)) {
/*do nothing*/
} else {
/*do something*/
}
something to do all the time:
}

Not exactly rocket science.

I know. This is why I wanted you to say what you mean by
maintainable. If code is maintainable despite having to make
such changes, I want to know what you consider to be harmful to
maintainability. Otherwise all code is maintainable (provided
it is clear) and you could have just said "this code is clear"
-- implying that it is therefore (by your definition)
maintainable. What, in addition to clarity, were you claiming
by saying it is maintainable?
IMO, ridiculous. Unnecessarily complex. You just want:

while (n--)
if (cond(n) {
/* do something */
}
/* something to do all the time */
}

No else, no continue, no extra lines, no confusion.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
Sep 22 '08 #28

P: n/a
Ben Bacarisse wrote:
Eric Sosman <es*****@ieee-dot-org.invalidwrites:

<snip>
>Hi, my name is Eric, and I'm a `continue' abuser. I use it as
a disguised `goto', simply to avoid excessive nesting:

<fx:stands up>
Hello, my name is Ben, and *I* abuse break. Ah, it feels so good
to say it out loud!

I never get tempted by continue (see elsethread) but I can't keep
my hands off that lovely break. It is sooooo tempting, when you
are all hot and bothered, tightly bound by a strict loop invariant,
just to slip in little break and be free.
Here is some more meat for disagreement and abuse. You can avoid
both break and continue. Simply use goto. Note that this has the
significant advantage that a short search of the code source shows
you the destination.

If the compiler can't optimize through this, I suspect the
optimizer is flawed.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
Sep 22 '08 #29

P: n/a
On 22 Sep, 15:52, Richard<rgr...@gmail.comwrote:
Chris Dollin <chris.dol...@hp.comwrites:
Richard wrote:
Chris Dollin <chris.dol...@hp.comwrites:
<snip>

[the continue version isn't as clear]
Says you. I have explained why it is contributing to clarity. What YOU
[expect] is immateterial here since you are coming from a mindset which
already says use of continue indicates a broken design.
you're mind reading...
I have given a
very simple use of it which is clear, concise and requires less code
browsing to *see what happens when an element is not suitable for
processing.

Here, I will show you again:

while(n--){

* *if(complexConditionNotMatched(n))
* * * continue; /* not interested. Check the next if there is one. */

* */*do processing of things we are interested in*/

}
<snip>
I think the above is very well designed and crystal clear.
yes but I think (and apparently a few other people) that

while(n--)
{
if (complexConditioMatched(n))
do_processing_of_thing();
}

is clearer. For a start it avoids an inverted test.
I don't write predicates with "not" in the name. So
I would have coded your original example as

while(n--){
if (!complexConditionMatched(n))
continue; /* not interested. Check the next if there is one. */

/*do processing of things we are interested in*/
}

there is some evidence (if forced to cite I'll try "The Psychology
of Computer Programming") that human beings (including computer
programnmers) prefer positive to negative logic.
--
Nick Keighley

When the Piranhas left school they were called up but were found
by an Army Board to be too unstable even for National Service.
Denied the opportunity to use their talents in the service of their
country, they began to operate what they called 'The Operation'.
They would select a victim and then threaten to beat him up if he
paid the so-called protection money. Four months later they started
another operation which the called 'The Other Operation'. In this
racket they selected another victim and threatened not to beat him
up if he didn't pay them. One month later they hit upon 'The Other
Other Operation'. In this the victim was threatened that if he
didn't pay them, they would beat him up. This for the Piranha
brothers was the turning point.
Monty Python The Pirana Brothers
Sep 23 '08 #30

P: n/a
Nick Keighley wrote:
is clearer. For a start it avoids an inverted test.
I don't write predicates with "not" in the name.
I don't think that's a fair criticism; I thought Richard's
`complexConditionNotMatched` was a standin for whatever
expression was required, with the `Not` showing intent,
not the actual presence of a `Not` in the name.
So
I would have coded your original example as

while(n--){
if (!complexConditionMatched(n))
continue; /* not interested. Check the next if there is one. */

/*do processing of things we are interested in*/
}

there is some evidence (if forced to cite I'll try "The Psychology
of Computer Programming") that human beings (including computer
programnmers) prefer positive to negative logic.
I think there are subsequent studies in that direction, but I
don't have a cite to hand. One of my rantettes is against languages
that don't have an `unless`.

--
'It changed the future .. and it changed us.' /Babylon 5/

Hewlett-Packard Limited registered office: Cain Road, Bracknell,
registered no: 690597 England Berks RG12 1HN

Sep 23 '08 #31

P: n/a
Chris Dollin wrote:
>
.... snip ...
>
I think there are subsequent studies in that direction, but I
don't have a cite to hand. One of my rantettes is against
languages that don't have an `unless`.
How about:

unless (x) if (y) z;
-->
if (!x && y) z; /* for C */

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
Sep 23 '08 #32

P: n/a
CBFalconer <cb********@yahoo.comwrites:
How about:

unless (x) if (y) z;
-->
if (!x && y) z; /* for C */
I suppose one could
#define unless(condition) if (!(condition))
but I would not advocate it.
--
Ben Pfaff
http://benpfaff.org
Sep 23 '08 #33

P: n/a
Ben Pfaff <bl*@cs.stanford.eduwrote:
CBFalconer <cb********@yahoo.comwrites:
How about:

unless (x) if (y) z;
-->
if (!x && y) z; /* for C */

I suppose one could
#define unless(condition) if (!(condition))
but I would not advocate it.
In other words, if you want PERL, you know where to find it.
(A sentiment which I heartily endorse.)

Richard
Sep 24 '08 #34

P: n/a
Ben Pfaff wrote:
CBFalconer <cb********@yahoo.comwrites:
>How about:

unless (x) if (y) z;
-->
if (!x && y) z; /* for C */

I suppose one could
#define unless(condition) if (!(condition))
but I would not advocate it.
Much as I like `unless`, I would not advocate this either. Dinking
around with control-structure macros is, I believe, a good way to
confuse the other programmers who might be working on your code.

/Sometimes/ you get enough ROI for it to be worthwhile, when the
macro(s) hide enough details in the right kind of way. I'm willing
to pay the !() price of an unless-less C; but any imperative language
I design has an `unless` conditional (and an `until` loop).

--
'It changed the future .. and it changed us.' /Babylon 5/

Hewlett-Packard Limited Cain Road, Bracknell, registered no:
registered office: Berks RG12 1HN 690597 England

Sep 24 '08 #35

P: n/a
Chris Dollin <ch**********@hp.comwrites:
Much as I like `unless`, I would not advocate this either. Dinking
around with control-structure macros is, I believe, a good way to
confuse the other programmers who might be working on your code.

/Sometimes/ you get enough ROI for it to be worthwhile, when the
macro(s) hide enough details in the right kind of way.
My favorite example of a worthwhile control structure macro is a
macro for iterating through linked lists constructed in clever
ways, so that code like

for (node = list; node != NULL; node = node->next) {
struct data *d = container_of(node, struct data, member);
...do something with d...
}

(or often much worse than that) can be condensed to something
like

struct data *d;
LIST_FOR_EACH (d, struct data, member, list) {
...do something with d...
}

which personally seems more readable.
--
char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa6 7f6aaa,0xaa9aa9f6,0x11f6},*p
=b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)break;else default:continue;if(0)case 1:putchar(a[i&15]);break;}}}
Sep 24 '08 #36

P: n/a
On 22 Sep 2008 at 21:48, CBFalconer wrote:
Simply use goto. Note that this has the significant advantage that a
short search of the code source shows you the destination.
More fantastic advice for the C newbie from CBF...

Sep 28 '08 #37

This discussion thread is closed

Replies have been disabled for this discussion.