This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Statements: break and continue
- To: LocKDowN <lockdown at usm dot dhs dot org>
- Subject: Re: Statements: break and continue
- From: Kevin Handy <kth at srv dot net>
- Date: Sat, 28 Jul 2001 13:12:13 -0600
- CC: gcc at gcc dot gnu dot org
- References: <000701c1173a$65237890$0200a8c0@lockdown>
LocKDowN wrote:
>
> Can't there be a break(depth) and continue(depth) to specify the deepness to
> act on?
> example:
>
> [some code]
> for (int x = 0; x < 10; x++) {
> for (int y = 0; y < 10; y++) {
> if (x == 5 && y == 8) {
> break(2); // get out of BOTH for loops
> }
> }
> }
> [some code]
This is no better than just using a goto. If you add another level of
loop
into the code, you will have to go back and search for all of the
break(n)'s
and adjust them (or not depending on n). If you want to do a goto, then
just
use a goto, don't hide it in syntactical sugar.
Also, using this syntax, you'd expect to be able to use 'break(i)' where
i
was a variable. Even if you limited it to constants, you would see
macro's
used like 'break(PLAZDAQ)', which would require more digging, only to
find
a '#define PLAZDAQ ZORGNA(DQZLE)?2:17' or some other such nonsense.
> This would be highly convenient as the workaround is unattractive.
What workaround? A goto? just because it is labeled as 'break' doesn't
change the fact it is a disguised goto, with a hidden label. goto's
aren't
evil, only the uses people put them to make them evil.
> PHP has this great feature, surprisingly.
> Perhaps you have not added this for standards compliance?
Standards are important, but this is just syntactical sugar around a
goto.
Break is usually easy to trace back to the loop it is breaking out of,
which is the last open loop, but this construct would only encourage
spaghetti code. Maybe useful in the obfuscated C contest, but a royal
pain
to maintainers.
> I'm mailing about this because this issue has always disturbed me.
> I'd like to have some insight on this matter...
It's too ugly. Think about the poor maintainers to come who have to
figure out the code of someone who tried too hard to be innovative.