NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/lang/cplus/12912

Internet Message Format | 1992-08-26 | 2.8 KB

Path: sparky!uunet!olivea!decwrl!deccrl!news.crl.dec.com!rdg.dec.com!decvax.dec.com!enigami.mv.com!enigami.mv.com!cory
From: [e-mail] (Cory Kempf)
Newsgroups: comp.lang.c++
Subject: Re: named loops
Message-ID: <[e-mail]>
Date: 26 Aug 92 15:48:41 GMT
Reply-To: [e-mail]
Organization: EnigamI, Inc., Nashua, NH
Lines: 55
X-Mailer: uAccess - Macintosh Release: 1.6v1


In article <[e-mail]> (comp.lang.c++), [e-mail] (Steve Clamage) writes:
>[e-mail] (Stephen J Bevan) writes:

>Second (a bit of nit-picking), the current "break" does not require a
>label, whereas "goto" does.  The proposed change adds a label to
>the main code and thus also to the "break".  This seems to me quite
>similar syntactically to the "goto", as shown in the example above.

A major difference is that the proposed change impliments a very highly
rigidly defined implimentation of a goto.  As I pointed out in a pervious
article on the subject, just about ever control structure is a form
of if/goto.  Defining a proposed change as being bad because it is
a form of goto would imply that all loops, switch statements, exception
handling, etc are also likewise bad.

All of these structures are essentually if/goto combinations, with
very rigid rules for how they can be used.  As such, they make the
code cleaner, and easier to read, because we know what the rules are
for a while loop, for example.  Goto's have very few rules.  When
you see a goto in code, you know that execution is jumping somewhere.
Where?

>The difference is the location of the label and whether there is a
>colon following it.  For better diagnostics in the presence of syntax
>errors and for consistency, it could be argued that the loop label
>should have a colon anyway.

Actually, this would be a bad idea.  In a case statement, execution
goes to the code imediately following the colon.  In a goto, execution
goes to the code imediately following the colon.

With a named loop, upon encountering a continue, execution goes on
to the next cycle, which begins somewhat after the label (especially
in the case of a for loop).  Upon encountering a break, execution
goes to the code after the end of the named loop, nowhere near the
colon.

Looks pretty inconsistant, to me.

Considering the state of most compiler diagnostics, I really wouldn't
bother using *THAT* as a justification for *ANYTHING*. (except, perhaps,
an *OSHA* standard for compiler diagnostics :-)  )

+C


-------------------------------------------------------------
Cory Kempf                    EnigamI, Inc.
[e-mail]           ...!decvax!enigami!cory
Annon:    [e-mail]

"F' cryin' out loud, it's *your* life; shouldn't you at least examine
your lifestyle values to see if they are really what *you* want."
                                        --Keith Lim