Is an argument to break, continue a bad idea?

[Aaron Henley]

henry at utzoo.uucp (Henry Spencer) writes:
>Why use loops, or ifs, or any other control structures, which replace some
>subset of the functionality of the goto?  Because they are easier to read
>and harder to make mistakes with.  The proposal wasn't to make break the
>same as goto, but to provide a way of using break to exit multiple levels
>of loops.  Since humans find counting levels difficult, one should tag the
>levels with names rather than requiring a count.  Nobody has suggested the
>equivalent of "#define break goto"; break would still be constrained to use
>only for exiting loops (well, and switches).  The constraint is important,
>indeed crucial; without it, one might as well use goto.

Noted, I misinterpreted this discussion, sorry.  Does break <label> statement
mean that the continue should also have a label?

>>... I do recommend people out there to
>>experiment with your code and look into your assembly listings if your
>>not sure of the best way to code a particular piece of code or if you
>>want to *REALLY* understand what your C code is doing!

>With a good optimizing compiler, you could spend all day just trying to
>figure out the relationship between what you wrote and what the compiler
>produced.  Not, generally, an enlightening exercise.  Also a fruitful source
>of misunderstandings, given the frequency of obscure compiler bugs.  To
>really understand C, you should study C, not assembler.

I have to disagree with this point.  I think people should and in many
cases must be aware of how their compiler allocates memory for structures,
what happens when you typecast a word from a memory location starting at a
point that isn't word aligned, etc...  These and many other usages of C are
ambiguously defined.  Just as there are a large frequency of obscure compiler
bugs, there are several ways different compilers handle ambiguous situations,
many of which cannot be found in the compiler's documentation.

My intent was not to suggest that you create a C program and then study
the assembly listing, but inorder to write efficient C code that does
what you want, you may have to consider what your compiler is generating.
So test the code in question in a small test program and see what the
assembly code looks like, neither of which should be time consuming.  If
your interest is very specific you should have little or no trouble tracking
down the functionality of the code in question.

Aaron
-- 
   ___________________________________________________________________
  /  Aaron Henley, Motorola Inc.      DISCLAIMER: std.disclaimer     /
 / Cellular Infrastructure Division   UUCP: ...!uunet!motcid!henley /
/__________________________________________________________________/