Hyman Rosen ha scritto:

> In Ada, it's actually
>     exit when condition;
> or  exit label when condition;
>
> Barnes claims that this was adopted as shorthand because exits from
> loops are such common constructs, and the alternative is wordier:
>     if condition then exit; end if;
>     if condition then exit label; end if;
>
> Since C++ doesn't require a closing 'end if' for its conditionals,
> I don't think we need a shorter version.

Yes and no. Consider the following (known as "loop and a half" unless
I'm mistaken):

   with Text_IO, Ada.Integer_Text_IO;
   use  Text_IO, Ada.Integer_Text_IO;
   procedure Print_Squares is
     X : Integer;
   begin
     loop
       Get(X);
     exit when X = 0;
       Put(X * X);
       New_Line;
     end loop;
   end Print_Squares;

My point is that "exit when ..." stands out, because it happens to
be easy to indent to convey such purpose, while the corresponding
"if (condition) break" does not (irrespective of labels, coming to
think of it).

On second thought, the above IMHO points out that the case when a
labeled break is most useful, breaking out of multiple loops, is
also the case when the break is the least obvious and easier to
miss - indenting it to line up with the loop being exited might
cause it to be missed because it is too far left (and might look
funny), indenting it normally might move it too far to the right.

(The example is from http://www.dwheeler.com/lovelace/s5s3.htm, in case
the formatting gets lost).

Davide Bolcioni
--
Paranoia is an afterthought.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Allan W" <allan_w@my-dejanews.com> wrote in message news:7f2735a5.0304280900.67d39121@posting.google.com...

> // "continue outer" here would be equivalent to "break" (from the
> // inner loop) but "break outer" would be completely different...
>
> >      s: switch (c)
> >      {
> >      case 'z':
> >          for (i = 1; i < 10; ++i)
> >              if (test(i))
> >                  break s;
> >      }
>
> Is that what was meant all along by "labeled break?" I like this
> idea a lot -- it does indeed seem superior to my idea of using
> an integer constant.

Yes, that is it.  You can read a more thorough description in Java language reference, 14.14 and 14.15.  (available on sun.com).  I assumed everyone here is familiar with the concept so didn't paste in the text.  [certainly the part about finally does not apply.]

> Labels like this would be compatible with existing language
> constructs ("goto outer" would still mean what it means today).
> The only part of the language that would need to change is
> the break statement itself. To maintain backwards compatibility,
> the label in "break" would be optional.

Exactly.


The 'against' arguments I read here were pretty strange.  On the line of nested loops shall not be used, swithh shall not be used, switch in a loop shall not be used. And one shall better change style, rearrange code, etc, instead of fixing the language. [overloading keyword break to break in switch AND a loop is a flaw by all means, isn't it?]

I mentally translate all those argunemts to other language constructs like casts. Those are bad, dangerous, etc. So why anyone with sane mind would work to introduce safer, usable versions, like static_cast or const_cast?      Huh?

Paul

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

ron@sensor.com ("Ron Natalie") writes:

|>  "James Kanze" <kanze@gabi-soft.de> wrote in message news:d6651fb6.030=
4300655.5ecff874@posting.google.com...
|>  > allan_w@my-dejanews.com (Allan W) wrote in message
|>  > news:<7f2735a5.0304291035.68c8c01b@posting.google.com>...

|>  > > Second, besides defining a reserved word (which is illegal),

|>  > It's only illegal if you do so before including a standard
|>  > header.  In practice, I doubt there is an implementation where
|>  > it will cause a problem.

|>  NO, it is illegal anywhere in a translation unit that includes a
|>  standard header.

Oops, you're right.

--=20
James Kanze                                  mailto:kanze@gabi-soft.fr
Conseils en informatique orient=E9e objet/
                      Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France  Tel. +33 1 41 89 80 93

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Davide Bolcioni wrote:
> IIRC the Ada break has another distinguishing feature: you could write
> the above like this
>                     break outer if (i + j == i * j);
>
> I guess the idea is that "if (condition) break" risks being overlooked
> because the break might end up far to the right, and a casual reader
> would miss the control path. Maybe this is just telling us that the
> construct has its drawbacks.

In Ada, it's actually
     exit when condition;
or  exit label when condition;

Barnes claims that this was adopted as shorthand because exits from
loops are such common constructs, and the alternative is wordier:
     if condition then exit; end if;
     if condition then exit label; end if;

Since C++ doesn't require a closing 'end if' for its conditionals,
I don't think we need a shorter version.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

allan_w@my-dejanews.com (Allan W) wrote in message
news:<7f2735a5.0304291035.68c8c01b@posting.google.com>...

> Second, besides defining a reserved word (which is illegal),

It's only illegal if you do so before including a standard header.  In
practice, I doubt there is an implementation where it will cause a
problem.

> it conflicts with existing uses of break without an argument.

Less conflicts here than with static.

>     #define break(where) goto where
>     void foo(int i) {
>         switch (i) {
>             case 0:
>                std::cout << "zero";
>                break;  // Oops! Now a compile error.

Not at all.  Did you try it?

In the define, break is a function-like macro.  As such, it will only be
recognized as a macro if the immediately following token is a '('.

>             /* Other cases, more errors... */
>         }
>     }

The real problem, of course, is that this macro doesn't do what the
desired break does, mainly leave the loop with the given label.  Still,
it achieves pretty much the same ends: program obfuscation.

--
James Kanze             GABI Software             mailto:kanze@gabi-soft.fr
Conseils en informatique orient   e objet/
                           Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, T   l. : +33 (0)1 30 23 45 16

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Allan W wrote:

> hyrosen@mail.com (Hyman Rosen) wrote
>
>>     outer: for (int i = 1; i < 10; ++i)
>>                for (int j = 1; j < 10; ++j)
>>                    if (i + j == i * j)
>>                        break outer;
>>                    else if (done(j))
>>                        continue outer;
>
>
> // "continue outer" here would be equivalent to "break" (from the
> // inner loop) but "break outer" would be completely different...
>
>
>>     s: switch (c)
>>     {
>>     case 'z':
>>         for (i = 1; i < 10; ++i)
>>             if (test(i))
>>                 break s;
>>     }
>
>
> Is that what was meant all along by "labeled break?" I like this
> idea a lot -- it does indeed seem superior to my idea of using
> an integer constant.

IIRC the Ada break has another distinguishing feature: you could write
the above like this

      outer: for (int i = 1; i < 10; ++i)
                 for (int j = 1; j < 10; ++j) {
                     break outer if (i + j == i * j);
                     ...
                 }

I guess the idea is that "if (condition) break" risks being overlooked
because the break might end up far to the right, and a casual reader
would miss the control path. Maybe this is just telling us that the
construct has its drawbacks.

Davide Bolcioni
--
Paranoia is an afterthought.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"James Kanze" <kanze@gabi-soft.de> wrote in message news:d6651fb6.0304300655.5ecff874@posting.google.com...
> allan_w@my-dejanews.com (Allan W) wrote in message
> news:<7f2735a5.0304291035.68c8c01b@posting.google.com>...
>
> > Second, besides defining a reserved word (which is illegal),
>
> It's only illegal if you do so before including a standard header.  In
> practice, I doubt there is an implementation where it will cause a
> problem.
>

NO, it is illegal anywhere in a translation unit that includes a standard header.



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

hyrosen@mail.com (Hyman Rosen) wrote
> If you have a label attached to a statement for which break or
> continue applies, and you are within that statement, then
> 'break label;' and 'continue label;' ... [should] have the
> effect of exiting or continuing that construct.
>      outer: for (int i = 1; i < 10; ++i)
>                 for (int j = 1; j < 10; ++j)
>                     if (i + j == i * j)
>                         break outer;
>                     else if (done(j))
>                         continue outer;

// "continue outer" here would be equivalent to "break" (from the
// inner loop) but "break outer" would be completely different...

>      s: switch (c)
>      {
>      case 'z':
>          for (i = 1; i < 10; ++i)
>              if (test(i))
>                  break s;
>      }

Is that what was meant all along by "labeled break?" I like this
idea a lot -- it does indeed seem superior to my idea of using
an integer constant.

Labels like this would be compatible with existing language
constructs ("goto outer" would still mean what it means today).
The only part of the language that would need to change is
the break statement itself. To maintain backwards compatibility,
the label in "break" would be optional.

My instinct (which is right more often than not, but certainly
not infallible) tells me that this wouldn't be too hard to
implement, either. No harder than implementing "continue" today.
Would anyone in a position to know (such as compiler vendors)
care to weigh in?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Dietmar Kuehl wrote:
[snip]
> Of course, this is due to personal style and the kind of applications I'm
> writing but from my perspective I would rather propose removal of 'break'
> to break out of loops, goto, and 'do...while()' than supporting a motion
> to enhance them. Well, there is an enhancement to goto's, though, which is
> quite useful to implement state machines: if labels can be stored in variables
> code for state machines can be improved both in terms of readability and
> performance. However, readability does not really matter since such beasts
> are generated anyway...
In the _CACM_ article mentioned in my last post, the types of programs
transformed were called "regular programs".  This is probably because
there's a very close correspondence between these programs and
"regular grammars". Aren't "state machines" very similar to "regular
grammars" in that each "state" corresponds to a non-terminal in
the grammar?  If so, then whats the need for storing labels in variables,
since the "states" are all constant?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

> ""Balog Pal"" <pasa@lib.hu> wrote
> : I hope the next standard will adopt the labeled break and continue without
>  much discussion and hesitation.

cdotrdotwood@verizondotnet.removeme ("C Wood") wrote
>     #define break(where) goto where

Are you suggesting that Balog should use this as an alternative to
the C++ enhancement?

First, this doesn't implement "labeled break" as I now understand it,
where the label goes at the beginning of the loop rather than at the
end. If you "goto" this label, you start the loop all over again.

Second, besides defining a reserved word (which is illegal), it
conflicts with existing uses of break without an argument.

    #define break(where) goto where
    void foo(int i) {
        switch (i) {
            case 0:
               std::cout << "zero";
               break;  // Oops! Now a compile error.
            /* Other cases, more errors... */
        }
    }

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Allan W" <allan_w@my-dejanews.com> wrote in message
news:7f2735a5.0304291035.68c8c01b@posting.google.com...
: > ""Balog Pal"" <pasa@lib.hu> wrote
: > : I hope the next standard will adopt the labeled break and continue
without
: >  much discussion and hesitation.
:
: cdotrdotwood@verizondotnet.removeme ("C Wood") wrote
: >     #define break(where) goto where
:
: Are you suggesting that Balog should use this as an alternative to
: the C++ enhancement?

    Correct.
:
: First, this doesn't implement "labeled break" as I now understand it,
: where the label goes at the beginning of the loop rather than at the
: end. If you "goto" this label, you start the loop all over again.

    Since it's "in the air" still, different ideas of how it should work are
still valid.  Appears to be a few different ideas of how it should work
floating around.
:
: Second, besides defining a reserved word (which is illegal), it
: conflicts with existing uses of break without an argument.

    My fault.

    Humorously enough, I did compile this, and run it.  Apparently my
compiler differentiates that it's a macro with different arguments.  Perhaps
we rename the macro named_break(label) and avoid the conflict.

<snip code>

    Did you actually compile your code?   I ran it on two compilers and it
worked fine.

    The point was to use goto, and not introduce something such as:
        break 1 or break label, when the behaviour would be so different
than one would expect.

    The OP could use exceptions if need be, although, that would be ugly and
considered bad style (not an error exceptions)

    That's all.




---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

NOSPAMsjhowe@dial.pipex.com ("Stephen Howe") wrote
> The drawback about
>
> break 2;
>
> is that you only have throw an extra loop round the existing loops and to
> break to the same place, the statements have to adjusted to
>
> break 3;
>
> I regard that as error prone.

Obviously neither of us have experience using numbered breaks (since
they don't currently exist). Your point is a valid concern. However, I
wonder how often this would occur.

Seems to me that if you throw an extra loop around the existing loops,
you normally would NOT need to adjust the breaks.

    // Old
    for (int i=0; i<10; ++i) {
        for (int j=0; j<10; ++j) {
            if (something) break 2; // Break out of I loop
        }
    }

    // New #1
    for (int a=0; a<10; ++a) {
        for (int i=0; i<10; ++i) {
            for (int j=0; j<10; ++j) {
                // STILL WORKS CORRECTLY
                if (something) break 2; // Break out of I loop
            }
        }
    }

Things would be different if you threw an extra loop BETWEEN
existing loops.

    // New #2
    for (int i=0; i<10; ++i) {
        for (int a=0; a<10; ++a)  {
            for (int j=0; j<10; ++j) {
                // OOPS! Should now be break 3
                if (something) break 2; // Break out of wrong loop!
            }
        }
    }

I suspect that this would be extremely rare... but yes, it would
need adjusting.

> In contrast,
>
> break somelabel;
>
> does not suffer that.

We have this today, except that break is spelled "goto" -- right?

> Having said all this, I wonder how often it is needed?
> I code every day and in past 4 years I could have used a labelled break just
> once.
> I made do with a goto out of a nested for loop which I regard as fine.
> I see nothing really wrong with the status quo on this one.

Another good point.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

James Kanze wrote:
>
> ron@sensor.com ("Ron Natalie") wrote in message
> news:<HIXpa.27674$MZ6.22254@fe05.atl2.webusenet.com>...
> > "Allan W" <allan_w@my-dejanews.com> wrote in message
> > news:7f2735a5.0304241224.713f0651@posting.google.com...
>
> > > How is a "labeled" break different than a "goto"?
>
> > > I hope that there will be much discussion and hesitation about
> > > expanding the power of break and continue. In particular, I hope
> > > that there is discussion about a statement like "break 2;" which
> > > breaks out two levels:
>
> > Ick...that's even a worse idea than than the named break.  You want to
> > count some number of loops, making sure you don't miscount blocks on
> > if's etc...that aren't break-able, hoping nobody sticks an extra loop
> > in there... you'd be much better off with a goto.
>
> Actually, his variable break is rather interesting.  Sort of a modern
> variant of an assigned goto in Fortran.

Considering that Fortran has dumped assigned goto as of the 1995
standard, that would tend to weigh against it.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Balog Pal wrote:
>
> I hope the next standard will adopt the labeled break and continue
> without much discussion and hesitation.

Fortran provides labeled loops and corresponding labeled control
statements, which might be of some use in composing similar ideas for
C++.  The "break" and "continue" parts are easy, but I'm not sure what
the best way would be to label a loop.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Lo   c Joly <loic.actarus.joly@wanadoo.fr> schrieb in im Newsbeitrag:
b8an7b$d1p$1@news-reader14.wanadoo.fr...
Balog Pal wrote:
> "Randy Maddox" <rmaddox@isicns.com> wrote in message
>I believe there is another way to solve that problem, that is more
>elegant that the goto :

>loop inside switch -> function inside switch, loop inside function and
>use of return

>nested loop -> function inside loop, loop inside function and use of return

This would not be much different from the usage of a flag.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Craig Powers wrote:
> Fortran provides labeled loops and corresponding labeled control
> statements, which might be of some use in composing similar ideas for
> C++.  The "break" and "continue" parts are easy, but I'm not sure what
> the best way would be to label a loop.

Ada has named loops, which are distinct from labels. Ada's labels look
like <<Label_Name>>, and are used by 'goto Label_Name;'; the labels are
supposed to be deliberately ugly and obtrusive. Named loops just have
an identifier and colon in front of them, and the label has to be repeated
at the end:
     L: for i in 1..N loop if Cond then exit L; end if; end loop L;
You can use the exit statement to break out of nested loops.

Named break and continue in C++ should work exactly the same way.
If you have a label attached to a statement for which break or
continue applies, and you are within that statement, then 'break label;'
and 'continue label;' have the effect of exiting or continuing that
construct.
     outer: for (int i = 1; i < 10; ++i)
                for (int j = 1; j < 10; ++j)
                    if (i + j == i * j)
                        break outer;
                    else if (done(j))
                        continue outer;
     s: switch (c)
     {
     case 'z':
         for (i = 1; i < 10; ++i)
             if (test(i))
                 break s;
     }

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

""Balog Pal"" <pasa@lib.hu> wrote in message
news:3ea74702@andromeda.datanet.hu...
: I hope the next standard will adopt the labeled break and continue without
much discussion and hesitation.
:
: Paul
:
    #define break(where) goto where

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

allan_w@my-dejanews.com (Allan W) wrote:
> Obviously the article was not describing C or C++, where exit(2)
> already has a well-defined meaning that has nothing to do with
> either break or goto.

... or the author felt that breaking out of the middle of a nested loop
is somewhat equivalent to 'std::terminate()'ing the program. Personally,
I think there are already enough structured and unstructured methods for
breaking out of anything that I don't need another one, in particular
none which is as unstructured as this.

Maybe it is a personal thing but here are some observations I found in my
code:

- Any "goto" I ever had in a C or C++ program was eventually removed and
  replaced by much cleaner code.
- Nearly all uses of 'break' to break out of a loop are replaced by much
  cleaner code. However, I break out of loops using 'return' statements
  quite frequently. I never felt the need to break out of nested loops.
- No use of 'do ... while()' I had made it into production code.

Of course, this is due to personal style and the kind of applications I'm
writing but from my perspective I would rather propose removal of 'break'
to break out of loops, goto, and 'do...while()' than supporting a motion
to enhance them. Well, there is an enhancement to goto's, though, which is
quite useful to implement state machines: if labels can be stored in variables
code for state machines can be improved both in terms of readability and
performance. However, readability does not really matter since such beasts
are generated anyway...
--
<mailto:dietmar_kuehl@yahoo.com> <http://www.dietmar-kuehl.de/>
Phaidros eaSE - Easy Software Engineering: <http://www.phaidros.com/>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

pasa@lib.hu ("Balog Pal") wrote in message news:<3ea74702@andromeda.datanet.hu>...
> I hope the next standard will adopt the labeled break and continue without much discussion and hesitation.
>
> Paul
>

Could you please clarify what a "labeled break and continue" are?  And
what problem they solve that goto does not?

Thanks.

Randy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

===================================== MODERATOR'S COMMENT:
 Warning:  please watch the tone of language in this discussion.


===================================== END OF MODERATOR'S COMMENT

"Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message news:i9RtLKFD44p+EwPd@robinton.demon.co.uk...
> In article <3ea74702@andromeda.datanet.hu>, Balog Pal <pasa@lib.hu>
> writes
> >I hope the next standard will adopt the labeled break and continue without much discussion and hesitation.
>
> Then write a paper and submit it.  To see the way we like such papers
> organised look at those that are already written to propose change to
> the core of the language.

I hope there is discusson and hesitation.   I have strong opinions against labeled break.
The do nothing to improve the language.  If you want to write hideous unstructured
code you should be stigmatized by having to use a goto.   Labeled break just lulls
people into thinking they are doing a good thing.

-


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Randy Maddox" <rmaddox@isicns.com> wrote in message news:8c8b368d.0304240458.8af5abd@posting.google.com...
> pasa@lib.hu ("Balog Pal") wrote in message news:<3ea74702@andromeda.datanet.hu>...
> > I hope the next standard will adopt the labeled break and continue without much discussion and hesitation.
> >
> > Paul
> >
>
> Could you please clarify what a "labeled break and continue" are?  And
> what problem they solve that goto does not?

The only thing they solve is that it keeps the label from inadvertantly getting
disassociated with the loop.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

pasa@lib.hu ("Balog Pal") wrote
> I hope the next standard will adopt the labeled break
> and continue without much discussion and hesitation.

How is a "labeled" break different than a "goto"?

I hope that there will be much discussion and hesitation about
expanding the power of break and continue. In particular, I
hope that there is discussion about a statement like "break 2;"
which breaks out two levels:

    for (int i=0; i<10; ++i) {
        for (int j=0; j<10; ++j) {
            for (int k=0; k<10; ++k) {
                int z = foo(i,j,k);
                if (z==2) break 2; // Equivalent to "goto nexti"
                if (z==1) break 1; // Equivalent to "break" or "goto nextj"
                // or better yet (if this is feasable):
                break z; // Equivalent to the two if() statements above
          nextk:
            }
      nextj:
        }
  nexti:
    }

Somehow I doubt that the variable form of break will work out well, but
I'd sure like to be able to use the constant version. Particularly handy
for a switch() statement embedded in a for() statement -- if one of the
cases wants to break out of the for, it currently has to use goto (or
else clear a flag and then continue). "break 2;" would solve this.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Allan W" <allan_w@my-dejanews.com> wrote in message news:7f2735a5.0304241224.713f0651@posting.google.com...

> How is a "labeled" break different than a "goto"?
>
> I hope that there will be much discussion and hesitation about
> expanding the power of break and continue. In particular, I
> hope that there is discussion about a statement like "break 2;"
> which breaks out two levels:

Ick...that's even a worse idea than than the named break.  You want
to count some number of loops, making sure you don't miscount blocks
on if's etc...that aren't break-able, hoping nobody sticks an extra loop in
there... you'd be much better off with a goto.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

===================================== MODERATOR'S COMMENT:
 Please wrap your text at <78 characters.


===================================== END OF MODERATOR'S COMMENT
"Randy Maddox" <rmaddox@isicns.com> wrote in message news:8c8b368d.0304240458.8af5abd@posting.google.com...

> Could you please clarify what a "labeled break and continue" are?  And
> what problem they solve that goto does not?

If you have a 2 way fork [if], and a control-transfer statement [goto], you can do any flow control you can imagine.    So you really don't need labeled breaks. Or labelles breaks. Or for, while, do loops. Or the switch.

But people generally try to avoid goto stuff, and use more structured elements.  Those restrict the power, taming it as a side effect.  You have a block, then it's easier to see how you get in and out.  Less chaos, more clarity.

Labeled break we need to cover some mistakes inherited.   Keyword break is overloaded, so you can't issue a break of a loop from inside a switch.   Also, when you have nested loops, you can't break to the outside from the inside.

Certainly you can, using a goto, and a label sticked to the { or }.  But it's not as readable as the break way, and also opens a chance that someone can insert code on the wrong end of that label.

Paul


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message news:i9RtLKFD44p+EwPd@robinton.demon.co.uk...

> Then write a paper and submit it.  To see the way we like such papers
> organised look at those that are already written to propose change to
> the core of the language.

Sure, I'm ready to do that, if it isn't yet filed. Can you point me to an URL or something describing the format of such papers?   And if it exists, the collection of proposals already filed?

I think this stuff was discussed ad nauseam, and everyone in the workgroup has a solid opinion. So it can go directly to vote, saving valuable time.

Paul

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

> I hope that there will be much discussion and hesitation about
> expanding the power of break and continue. In particular, I
> hope that there is discussion about a statement like "break 2;"
> which breaks out two levels:

The drawback about

break 2;

is that you only have throw an extra loop round the existing loops and to
break to the same place, the statements have to adjusted to

break 3;

I regard that as error prone.

In contrast,

break somelabel;

does not suffer that.

Having said all this, I wonder how often it is needed?
I code every day and in past 4 years I could have used a labelled break just
once.
I made do with a goto out of a nested for loop which I regard as fine.
I see nothing really wrong with the status quo on this one.

Stephen Howe


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

allan_w@my-dejanews.com (Allan W) wrote in message news:<7f2735a5.0304241224.713f0651@posting.google.com>...
>
[snip]
> Somehow I doubt that the variable form of break will work out well, but
> I'd sure like to be able to use the constant version. Particularly handy
> for a switch() statement embedded in a for() statement -- if one of the
> cases wants to break out of the for, it currently has to use goto (or
> else clear a flag and then continue). "break 2;" would solve this.
This "break 2;" is equivalent to "exit(2)" as described in article
"Syntactic Source to Source Transforms and Program Manipulation" by
Arsac in _CACM_:22:1.  It could be very useful in translating goto
programs into
"break n" programs.  The article provided an algorithm to do that.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

ron@sensor.com ("Ron Natalie") wrote in message
news:<HIXpa.27674$MZ6.22254@fe05.atl2.webusenet.com>...
> "Allan W" <allan_w@my-dejanews.com> wrote in message
> news:7f2735a5.0304241224.713f0651@posting.google.com...

> > How is a "labeled" break different than a "goto"?

> > I hope that there will be much discussion and hesitation about
> > expanding the power of break and continue. In particular, I hope
> > that there is discussion about a statement like "break 2;" which
> > breaks out two levels:

> Ick...that's even a worse idea than than the named break.  You want to
> count some number of loops, making sure you don't miscount blocks on
> if's etc...that aren't break-able, hoping nobody sticks an extra loop
> in there... you'd be much better off with a goto.

Actually, his variable break is rather interesting.  Sort of a modern
variant of an assigned goto in Fortran.  Very useful for obfuscation,
and laying traps for maintenance programmers.  Job security, maybe?
(Although how secure is your job if even you can't modify your code).

If the goal is to improve the quality of code written in the language
(which I don't really think is, nor necessarily should be, the case
either), then the solution would be more along the lines of creating a
working version of switch, and then deprecating and eventually
eliminating break and continue entirely; except for terminating a case
in a switch, I can't see any use for them in cleanly written code.

--
James Kanze             GABI Software             mailto:kanze@gabi-soft.=
fr
Conseils en informatique orient=E9e objet/
                           Beratung in objektorientierter Datenverarbeitu=
ng
11 rue de Rambouillet, 78460 Chevreuse, France, T=E9l. : +33 (0)1 30 23 4=
5 16

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Balog Pal wrote:
> "Randy Maddox" <rmaddox@isicns.com> wrote in message
>=20
>> Could you please clarify what a "labeled break and continue" are?
>> And what problem they solve that goto does not?
>=20
>=20
> You have a block, then it's easier to see how
> you get in and out.  Less chaos, more clarity. Labeled break we need
> to cover some mistakes inherited.   Keyword break is overloaded, so
> you can't issue a break of a loop from inside a switch.   Also, when
> you have nested loops, you can't break to the outside from the
> inside. Certainly you can, using a goto, and a label sticked to the {
> or }.  But it's not as readable as the break way, and also opens a
> chance that someone can insert code on the wrong end of that label.

I believe there is another way to solve that problem, that is more=20
elegant that the goto :

loop inside switch -> function inside switch, loop inside function and=20
use of return

nested loop -> function inside loop, loop inside function and use of retu=
rn

--=20
Lo=EFc

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

> allan_w@my-dejanews.com (Allan W) wrote
> > Somehow I doubt that the variable form of break will work out well, but
> > I'd sure like to be able to use the constant version. Particularly handy
> > for a switch() statement embedded in a for() statement -- if one of the
> > cases wants to break out of the for, it currently has to use goto (or
> > else clear a flag and then continue). "break 2;" would solve this.

jcampbell3@prodigy.net (Larry Evans) wrote
> This "break 2;" is equivalent to "exit(2)" as described in article
> "Syntactic Source to Source Transforms and Program Manipulation" by
> Arsac in _CACM_:22:1.  It could be very useful in translating goto
> programs into
> "break n" programs.  The article provided an algorithm to do that.

Obviously the article was not describing C or C++, where exit(2)
already has a well-defined meaning that has nothing to do with
either break or goto.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

I hope the next standard will adopt the labeled break and continue without much discussion and hesitation.

Paul

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <3ea74702@andromeda.datanet.hu>, Balog Pal <pasa@lib.hu>
writes
>I hope the next standard will adopt the labeled break and continue without much discussion and hesitation.

Then write a paper and submit it.  To see the way we like such papers
organised look at those that are already written to propose change to
the core of the language.


--
ACCU Spring Conference 2003 April 2-5
The Conference you should not have missed
ACCU Spring Conference 2004 Late April
Francis Glassborow      ACCU

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]