chrisnewton@no.junk.please.btinternet.com (Chris Newton) wrote in message
news:<bh9es3$e0v$1@titan.btinternet.com>...
>
> I disagree. Many of the functions I work with daily use nested loops as
> part of some mathematical algorithm. If we find the information we need
> early, it is appropriate to break out of as many loops as possible
> immediately. Currently, there is no construct in C++ that represents
> this concept, although it is a common action in practice.
>
> I would rather have a construct that implies exiting nested loops to
> some clearly specified level than use the less meaningful "goto".
>
> I'd prefer to jump to a clearly specified location, which is what goto
> does. Jumping to a clearly specified level leaves the actual location
> of the jump vulnerable to code reorganizations, causing a maintenance
> nightmare.


Why not put the loops in a function and simply return from the function when
you are ready to early out?  You can't get much more clear or
maintenance-proof than that.

Ken


---
[ 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                       ]

Ken Alverson wrote...
> Why not put the loops in a function and simply return from the
> function when you are ready to early out?  You can't get much more
> clear or maintenance-proof than that.

Why not? Because it doesn't represent what's happening, that's why not. :-)

I'm talking about non-trivial mathematical algorithms, typically
operating over complicated graph-like data structures in my particular
case. The inner parts of the loops make perfect sense in context, but
are meaningless without it. What would I call the inner function? How do
I give it a sensible interface, if it needs access to several local
variables available within the main function? Do I have to pass a dozen
references to local variables in the outer loops every time I call it?

What you suggest makes sense for some functions, which can naturally be
broken down into simpler components, each meaningful in its own right
and having a clear interface, and then glued together by some central
core representing the high level algorithm. Not all algorithms work that
way, though.

For the sort of thing I'm talking about, what your proposal does is take
what should have been a simple one-line expression of an exit condition,
and turn it into several lines of overhead and a disjointed set of
meaningless functions that's hard to follow and a maintenance nightmare.
I'll stick with goto, thanks. :-)

Regards,
Chris

---
[ 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 Kuyper wrote:
> I'd prefer to jump to a clearly specified location, which is what goto
> does. Jumping to a clearly specified level leaves the actual location
> of the jump vulnerable to code reorganizations, causing a maintenance
> nightmare.

That's why the correct way to do this is 'break label;' where the
label is attached to the beginning of the loop/switch construct.
This makes both the nature and destination of the jump clearly
defined and immune from maintenance rearrangements.

---
[ 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                       ]

"Chris Newton" <chrisnewton@no.junk.please.btinternet.com> wrote in message
news:bhr8pq$hd2$1@titan.btinternet.com...
>
> I'm talking about non-trivial mathematical algorithms, typically
> operating over complicated graph-like data structures in my particular
> case. The inner parts of the loops make perfect sense in context, but
> are meaningless without it. What would I call the inner function? How do
> I give it a sensible interface, if it needs access to several local
> variables available within the main function? Do I have to pass a dozen
> references to local variables in the outer loops every time I call it?

If it requires a lot of context, then perhaps encapsulating the algorithm in a
class with member functions is an appropriate course of action.  A member
function has access to all the class's context without passing around tons of
parameters.

Perhaps you have an example of an algorithm that cannot easily be broken into
separate functions while remaining coherent?

> For the sort of thing I'm talking about, what your proposal does is take
> what should have been a simple one-line expression of an exit condition,
> and turn it into several lines of overhead and a disjointed set of
> meaningless functions that's hard to follow and a maintenance nightmare.
> I'll stick with goto, thanks. :-)

Personally, I've rarely found a situation where the functions that would be
created by breaking apart a larger function would be "meaningless".  However,
I will admit that knowing how and where to break things up logically does
require some finesse.  Even though it may increase the size of the source
file, in my experience it almost always increases readability and
maintainability.

Ken


---
[ 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                       ]

Ken Alverson wrote...
> If it requires a lot of context, then perhaps encapsulating the
> algorithm in a class with member functions is an appropriate course
> of action. A member function has access to all the class's context
> without passing around tons of parameters.

Unfortunately, this suffers many of the same disadvantages as the
original proposal. For example...

1. The member functions have no particular meaning in themselves.

2. The places where functions are separated out are somewhat arbitrary.

3. Even if you initially decide to split where there is a need for a
multilevel break (to be implemented via a function return), you cannot
maintain this approach if different parts of the algorithm can break out
to different levels; that would require the use of exceptions rather
than a simple return statement.

4. You lose some of the scoping protections afforded by local variables,
since you effectively make all local data global to the whole algorithm
by representing them as members of a class.

5. You risk incurring performance overheads in what are typically very
time-sensitive algorithms.

> Perhaps you have an example of an algorithm that cannot easily be
> broken into separate functions while remaining coherent?

It's hard to give a full example; the algorithms I'm considering
wouldn't make much sense without background knowledge. I'm hesitant to
give any detailed descriptions since the code I'm talking about belongs
to my employer, and obviously I have a duty not to disclose any
sensitive information.

In summary, however, the particular cases I'm thinking of are
sophisticated graph searching algorithms. They look for particular
configurations of nodes with certain properties and in certain positions
relative to one another. This necessarily requires a certain amount of
deep nesting. Just as no part of the configuration makes sense out of
context, so no part of the algorithm to search for it is meaningful
without the code either side of it.

> Personally, I've rarely found a situation where the functions that
> would be created by breaking apart a larger function would be
> "meaningless". However, I will admit that knowing how and where to
> break things up logically does require some finesse. Even though it
> may increase the size of the source file, in my experience it almost
> always increases readability and maintainability.

For many simple algorithms, I agree with you. In the cases I describe,
however, the algorithm is complete and self-contained. We have become
quite adept at writing modular code in our field of expertise, and do so
when we can, but sometimes it simply doesn't make sense. Trying to
separate a unified whole here just harms the readability and
maintainability -- believe me, we've tried it often enough in some of
the longer algorithms.

What is required here is a way to escape from within nested loops to a
certain outer loop, and that's all there is to it. C++ provides for
functions, and exceptions, and loops, and labels, and even a
single-level break. Is a "break-to-labelled-loop" construct, a trivial
extension that expresses the required concept in a single line, really
so much more to ask?

Regards,
Chris

---
[ 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 <bhr8pq$hd2$1@titan.btinternet.com>, Chris Newton
<chrisnewton@no.junk.please.btinternet.com> writes
>For the sort of thing I'm talking about, what your proposal does is
>take what should have been a simple one-line expression of an exit
>condition, and turn it into several lines of overhead and a disjointed
>set of meaningless functions that's hard to follow and a maintenance
>nightmare. I'll stick with goto, thanks. :-)

Please give a real world example (i.e. publish some source) because
there is a credibility gap.


--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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@robinton.demon.co.uk> wrote in message
news:dRtiABBXFVQ$Ew3X@robinton.demon.co.uk...
> In article <bhr8pq$hd2$1@titan.btinternet.com>, Chris Newton
> <chrisnewton@no.junk.please.btinternet.com> writes
> >For the sort of thing I'm talking about, what your proposal does is
> >take what should have been a simple one-line expression of an exit
> >condition, and turn it into several lines of overhead and a disjointed
> >set of meaningless functions that's hard to follow and a maintenance
> >nightmare. I'll stick with goto, thanks. :-)
>
> Please give a real world example (i.e. publish some source) because
> there is a credibility gap.

I can think of one that fits Chris' description:  MinMax game tree
search algorithm with alpha-beta pruning.  An alpha cutoff skips
from odd level (of the game position tree) to odd level, and beta
cutoff jumps from even level to even level.  They overlap in a way
which makes it impossible to make a function in which both needs
are satisfied by a single function having multiple nested loops and
a return in the innermost one.  This is further complicated by the
fact that the tree traversal generally needs recursive function calls
anyway.

Using catch/throw (and I know this is heretic!) as a flow control
mechanism solves this problem brilliantly.

Cheers!

 - Risto -


---
[ 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 <bhrpae$kr2$1@hercules.btinternet.com>, Chris Newton
<chrisnewton@no.junk.please.btinternet.com> writes
>What is required here is a way to escape from within nested loops to a
>certain outer loop, and that's all there is to it. C++ provides for
>functions, and exceptions, and loops, and labels, and even a
>single-level break. Is a "break-to-labelled-loop" construct, a trivial
>extension that expresses the required concept in a single line, really
>so much more to ask?

We do not normally consider adding syntax to C++ to meet the needs of a
very restricted sub-community. If it really matters to that community
they need to put their money on the line by sponsoring someone to pursue
their cause at WG21 meetings. That seems fair, if it matters that much
then the group concerned should be willing to do the work (and I think
that it might prove to be far from trivial.

I can see nothing wrong with using goto in order to solve such a
specialist problem (After all Knuth used Pascal's global goto to solve a
problem he had in writing TeX) Adding syntax to C++ just to meet the
doctrinal purity of 'never use goto' does not seem to be a good use of
our time.


--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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                       ]

chrisnewton@no.junk.please.btinternet.com (Chris Newton) wrote in message news:<bhr8pq$hd2$1@titan.btinternet.com>...
> Ken Alverson wrote...
> > Why not put the loops in a function and simply return from the
> > function when you are ready to early out?  You can't get much more
> > clear or maintenance-proof than that.
>
> Why not? Because it doesn't represent what's happening, that's why not. :-)
>
> I'm talking about non-trivial mathematical algorithms, typically
> operating over complicated graph-like data structures in my particular
> case. The inner parts of the loops make perfect sense in context, but
> are meaningless without it. What would I call the inner function? How do
> I give it a sensible interface, if it needs access to several local
> variables available within the main function? Do I have to pass a dozen
> references to local variables in the outer loops every time I call it?

Why not use a function object? All of these local variables become members
and can be accessed directly. The context (of "meaningfulness") for the
smaller parts is given by the function object, too.

>
> What you suggest makes sense for some functions, which can naturally be
> broken down into simpler components, each meaningful in its own right
> and having a clear interface, and then glued together by some central
> core representing the high level algorithm. Not all algorithms work that
> way, though.
>
> For the sort of thing I'm talking about, what your proposal does is take
> what should have been a simple one-line expression of an exit condition,
> and turn it into several lines of overhead and a disjointed set of
> meaningless functions that's hard to follow and a maintenance nightmare.
> I'll stick with goto, thanks. :-)
>
> Regards,
> Chris
>
> ---
> [ 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                       ]

---
[ 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 wrote:
> Adding syntax to C++ just to meet the doctrinal purity of
 > 'never use goto' does not seem to be a good use of our time.

This might be a valid argument if the language did not already
contain 'break' and 'continue' statements.

---
[ 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 wrote...
> Please give a real world example (i.e. publish some source) because
> there is a credibility gap.

I'm sorry you feel that way. As I've already noted in this thread, I am
not at liberty to publish any real code for the particular situations I
was describing, because I don't own that code. However, I will try to
provide a much simplified example that I hope will make the point.

Consider a graph (V, E), where each vertex v in V has an associated
non-negative integer value and each edge e in E has an associated
non-negative integer weight. Suppose we require an algorithm that can
detect from among that graph any sets of four distinct vertices {v1,
..., v4} and corresponding sets of five distinct edges {e1, ..., e5}
with the following properties.

v1 has value 1.
v2 has value 2.
v3 has value 3 or 4.
v4 has a value equal to v3's.

e1 lies between v1 and v2 and has weight 1.
e2 lies between v2 and v3 and has weight 2 or 3.
e3 lies between v3 and v4 and has weight equal to the value of v3.
e4 lies between v4 and v1 and has weight equal to e2's.
e5 lies between v1 and v3 and has weight less than e3.

I hope it is clear that such an algorithm will inevitably require
several nested searches, however you choose to dress them up.

For efficiency reasons we require the algorithm to break out of the
inner loops as far as possible as soon as it is known that we can not
find the required configuration from the current state. Clearly, the
theoretical complexity of this particular algorithm is nasty, but in
practice other constraints mean that with a suitable optimisation of the
flow control, an acceptable level of performance can be achieved.

In such an algorithm, the use of "break to labelled loop" or "continue
from labelled loop" syntax could make the code considerably more
readable. Yes, it is possible to do it with goto, putting labels just
before or after the end of a particular loop (or both) and jumping there
to simulate the break or continue. If that were an ideal solution,
however, we wouldn't need break or continue at all. Heck, let's do away
with loops altogether, they're redundant too.

The simple fact remains that these concepts are useful for designing
algorithms, and so language support to express them naturally is useful
for implementing algorithms in a readable and maintainable way. I'd
wager that people who use data structures and algorithms more complex
than what you learn in a first year CS course make up a sizeable
proportion of C++ users, and although my particular example is quite
specific, it's not hard to find other similarly complex situations where
these constructs would be useful, if you choose to look.

I guess I just can't understand the opposition here. Is it really asking
too much to make a widely requested, 100% safe, 100% compatible, trivial
to implement change to support a large subset of C++ users?

Regards,
Chris


---
[ 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                       ]

"Hyman Rosen" <hyrosen@mail.com> a    crit dans le message de
news:1061234532.14365@master.nyc.kbcfp.com...
> James Kuyper wrote:
> > I'd prefer to jump to a clearly specified location, which is what goto
> > does. Jumping to a clearly specified level leaves the actual location
> > of the jump vulnerable to code reorganizations, causing a maintenance
> > nightmare.
>
> That's why the correct way to do this is 'break label;' where the
> label is attached to the beginning of the loop/switch construct.
> This makes both the nature and destination of the jump clearly
> defined and immune from maintenance rearrangements.
>

Then you can almost have what you want with a define

#define breakto goto
#define continueto goto

for (...)
{
    some code

    for (...)
    {
        if (cond1)
            continueto(next_outer_loop_iter);
        else if (cond2)
            break_to(outer_loop_end);
    }

    more code...

    next_outer_loop_iter::
}

outer_loop_end:

more code...


You can break and continue where you want and you can clearly
document the nature of the jump

---
[ 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 <bhu0q7$c31$1@titan.btinternet.com>, Chris Newton
<chrisnewton@no.junk.please.btinternet.com> writes
>I guess I just can't understand the opposition here. Is it really
>asking too much to make a widely requested, 100% safe, 100% compatible,
>trivial to implement change to support a large subset of C++ users?

It is the belief that this is a trivial change that I would question. In
a language as complicated as C++ very few changes are trivial. Thinking
that a change is trivial is often a symptom of not understanding the
degree to which things are interdependent.

I would also question the assertion that it is widely requested. Were
that the case there would be several proponents for it active in WG21
which is largely made up of experienced and active programmers from a
wide range of backgrounds.


--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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                       ]

Philippe Mori wrote:
> Then you can almost have what you want with a define

Not only is this ugly, but the label is not attached to the
construct being exited or repeated, and in fact there is no
place to put the labels if the construct does not use a
brace-enclosed compound statement.

No one would ever use such a 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                       ]

francis@robinton.demon.co.uk (Francis Glassborow) writes:

> In article <bhrpae$kr2$1@hercules.btinternet.com>, Chris Newton
> <chrisnewton@no.junk.please.btinternet.com> writes
>> What is required here is a way to escape from within nested loops to
>> a certain outer loop, and that's all there is to it. C++ provides
>> for functions, and exceptions, and loops, and labels, and even a
>> single-level break. Is a "break-to-labelled-loop" construct, a
>> trivial extension that expresses the required concept in a single
>> line, really so much more to ask?
>
> We do not normally consider adding syntax to C++ to meet the needs of
> a very restricted sub-community. If it really matters to that
> community they need to put their money on the line by sponsoring
> someone to pursue their cause at WG21 meetings. That seems fair, if it
> matters that much then the group concerned should be willing to do the
> work (and I think that it might prove to be far from trivial.
>
> I can see nothing wrong with using goto in order to solve such a
> specialist problem (After all Knuth used Pascal's global goto to solve
> a problem he had in writing TeX) Adding syntax to C++ just to meet the
> doctrinal purity of 'never use goto' does not seem to be a good use of
> our time.
[snip]

Labeled break and continue does not meet 'the doctrinal purity of
    'never use goto''. I don't think that is the goal, either; I for
    one would still expect to use goto from time to time.

The goal is to provide a compile-time-restricted goto that makes it
    easier to find the target label, in certain commonly occuring
    cases. It is a simple extension of the reasoning that provided
    break and continue in the first place.

---
[ 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 wrote...
> It is the belief that this is a trivial change that I would question. In
> a language as complicated as C++ very few changes are trivial. Thinking
> that a change is trivial is often a symptom of not understanding the
> degree to which things are interdependent.

C++ is indeed vastly overcomplicated at time, but I can't see anything
whatsoever about the suggested change that isn't trivial to specify and
implement. It consists of allowing a label immediately before a loop
statement to be interpreted differently if it's jumped to by a break or
continue than by a goto. Implementing this requires the same mechanics
as jumping (via goto) to a label at the end of the loop, either just
after it or just before the "continue" logic. What's the catch?

> I would also question the assertion that it is widely requested. Were
> that the case there would be several proponents for it active in WG21
> which is largely made up of experienced and active programmers from a
> wide range of backgrounds.

WG21 is hardly a universal representation of the millions of C++
programmers around the world. There aren't enough people in the
workgroup to have just one of them with experience of each field where
C++ is used, nor even close.

That said, yesterday I submitted the following in a reply to another of
Francis's messages. It seems not to have been put on the group for some
reason; I can only assume that one of the moderators didn't get it and
rejected the post.

"On 11 September 2000, in a post to comp.lang.c++ and
comp.lang.c++.moderated, a respected C++ expert who is not famed for
mincing his words wrote the following:

   "I would love to see 'continue label' and 'break label' but
unfortunately it is too late (well perhaps added as an option?)"

The prosecution rests."

The point, of course, is that the respected C++ expert in question was
Francis. And he's not the only person interested in this; try a quick
search of the Usenet archives for C++ groups, and spot the hundreds of
posts discussing this issue going back for years. Look at how widely
used the feature is in languages that offer it in directly equivalent
circumstances: not all the time, unsurprisingly, but certainly frequent
enough to merit consideration.

I stand by everything I claimed before: this change is safe, backward
compatible, trivial to implement and desirable to a lot of C++
programmers. If you dispute this, please provide some concrete reasons
for doing so that we can consider. Post a comment about my example of a
complicated algorithm or Risto's, and show how such algorithms can be
expressed neatly with current C++. Offer a neat technique the rest of us
don't know for simulating this effect cleanly. Cite a study that shows
this feature is almost universally abused when present in other
languages. But please, just give us something solid to discuss. Alluding
to complications that might exist, or suggesting that almost no-one else
agrees with me, are not constructive arguments.

Regards,
Chris

---
[ 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                       ]

rlankine@hotmail.com ("Risto Lankinen") writes:

> "Francis Glassborow" <francis@robinton.demon.co.uk> wrote in message
> news:dRtiABBXFVQ$Ew3X@robinton.demon.co.uk...
>> In article <bhr8pq$hd2$1@titan.btinternet.com>, Chris Newton
>> <chrisnewton@no.junk.please.btinternet.com> writes
>> >For the sort of thing I'm talking about, what your proposal does is
>> >take what should have been a simple one-line expression of an exit
>> >condition, and turn it into several lines of overhead and a disjointed
>> >set of meaningless functions that's hard to follow and a maintenance
>> >nightmare. I'll stick with goto, thanks. :-)
>>
>> Please give a real world example (i.e. publish some source) because
>> there is a credibility gap.
>
> I can think of one that fits Chris' description:  MinMax game tree
> search algorithm with alpha-beta pruning.  An alpha cutoff skips
> from odd level (of the game position tree) to odd level, and beta
> cutoff jumps from even level to even level.  They overlap in a way
> which makes it impossible to make a function in which both needs
> are satisfied by a single function having multiple nested loops and
> a return in the innermost one.  This is further complicated by the
> fact that the tree traversal generally needs recursive function calls
> anyway.
>
> Using catch/throw (and I know this is heretic!) as a flow control
> mechanism solves this problem brilliantly.

Or maybe not. Sometimes (actually, every time I've seen a game tree in
    my professional work) performance in a game tree search is important
    - and then the fact that goto is often hundreds of times faster
    makes a big difference.

---
[ 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 <bi10ij$7sn$1@hercules.btinternet.com>, Chris Newton
<chrisnewton@no.junk.please.btinternet.com> writes
>  "I would love to see 'continue label' and 'break label' but
>unfortunately it is too late (well perhaps added as an option?)"
>
>The prosecution rests."
>
>The point, of course, is that the respected C++ expert in question was
>Francis. And he's not the only person interested in this; try a quick
>search of the Usenet archives for C++ groups, and spot the hundreds of
>posts discussing this issue going back for years. Look at how widely
>used the feature is in languages that offer it in directly equivalent
>circumstances: not all the time, unsurprisingly, but certainly frequent
>enough to merit consideration.

:-) But in the intervening 3 years we have started to draft changes and
priorities.

>
>I stand by everything I claimed before: this change is safe, backward
>compatible, trivial to implement and desirable to a lot of C++
>programmers. If you dispute this, please provide some concrete reasons
>for doing so that we can consider. Post a comment about my example of a
>complicated algorithm or Risto's, and show how such algorithms can be
>expressed neatly with current C++. Offer a neat technique the rest of
>us don't know for simulating this effect cleanly. Cite a study that
>shows this feature is almost universally abused when present in other
>languages. But please, just give us something solid to discuss.
>Alluding to complications that might exist, or suggesting that almost
>no-one else agrees with me, are not constructive arguments.

No but the answer is very simple, draft a proposal including text for
the next Standard and submit it to WG21's evolution group. If it is
indeed as trivial as you suggest then it will not take you very long to
do so. Of course the compiler implementors may then have something to
say about it.


--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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:<3f321240@andromeda.datanet.hu>...
> "Francis Glassborow" <francis@robinton.demon.co.uk> wrote in message
> news:TjKB8sARQHG$EwEb@robinton.demon.co.uk...
>
> > Personally I am against it would just help bad programmers to write even
> > worse code.
>
> IMHO a language design shall just dismiss the 'bad and ignorant programmer'
> issue.  At least a language on the C/C++ level definitely.  A bad programmer
> can make uncountable many problems using UB already, break, goto and similar
> stuff is just a teardrop in the ocean.
> [Also, those bad programmers will likely not even know about the new
> feature, they aren't bad for no reason are they? ;-]
>
> The important thing is to support the good programmers, those willing to
> write good and even better code.    And the labeled form of break/continue
> we know in (eg. ) java is something that
> - doesn't break existing code
> - is almost trivial to implement
> - gives way to write more expressive and safe code
> - introduce no new way to shoot yourself in the foot

I think you're misunderstanding his objection. He seems to disagree
with your third point, because otherwise your third point would be
something more than "just help[ing] bad programmers to write even
worse code". I think he's saying that it would NOT create "more
expressive and safe code", that only bad programmers would use this
feature, and that they would use it only to create code that is even
worse than they could have written without this feature. That seems a
reasonable assessment to me.

---
[ 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 Kuyper wrote...
> I think he's saying that it would NOT create "more expressive and
> safe code", that only bad programmers would use this feature, and
> that they would use it only to create code that is even worse than
> they could have written without this feature. That seems a reasonable
> assessment to me.

I disagree. Many of the functions I work with daily use nested loops as
part of some mathematical algorithm. If we find the information we need
early, it is appropriate to break out of as many loops as possible
immediately. Currently, there is no construct in C++ that represents
this concept, although it is a common action in practice.

I would rather have a construct that implies exiting nested loops to
some clearly specified level than use the less meaningful "goto".
Cluttering my code with useless temporary booleans and extra conditions
to exit the loops one at a time doesn't even rate on my scale of helpful
solutions; it's just distracting clutter. Pulling out some inner part of
a loop into a separate function, even though it has neither use nor
meaning out of context, is even worse, and logically doesn't do anything
except replace a break-labelled-loop with a return anyway.

Labelled loops and corresponding break and continue statements are a
widespread, effective and natural way to represent a common programming
requirement. Given we're "up to but not including" anyway, what's the
problem with providing the final link in the chain?

Regards,
Chris

---
[ 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                       ]

chrisnewton@no.junk.please.btinternet.com (Chris Newton) wrote in message news:<bh9es3$e0v$1@titan.btinternet.com>...
> James Kuyper wrote...
> > I think he's saying that it would NOT create "more expressive and
> > safe code", that only bad programmers would use this feature, and
> > that they would use it only to create code that is even worse than
> > they could have written without this feature. That seems a reasonable
> > assessment to me.
>
> I disagree. Many of the functions I work with daily use nested loops as
> part of some mathematical algorithm. If we find the information we need
> early, it is appropriate to break out of as many loops as possible
> immediately. Currently, there is no construct in C++ that represents
> this concept, although it is a common action in practice.
>
> I would rather have a construct that implies exiting nested loops to
> some clearly specified level than use the less meaningful "goto".

I'd prefer to jump to a clearly specified location, which is what goto
does. Jumping to a clearly specified level leaves the actual location
of the jump vulnerable to code reorganizations, causing a maintenance
nightmare.

---
[ 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                       ]

Chris Newton <chrisnewton@no.junk.please.btinternet.com> wrote:
> James Kuyper wrote...
>> I think he's saying that it would NOT create "more expressive and
>> safe code", that only bad programmers would use this feature, and
>> that they would use it only to create code that is even worse than
>> they could have written without this feature. That seems a reasonable
>> assessment to me.

> I disagree. Many of the functions I work with daily use nested loops as
> part of some mathematical algorithm. If we find the information we need
> early, it is appropriate to break out of as many loops as possible
> immediately. Currently, there is no construct in C++ that represents
> this concept, although it is a common action in practice.

What prevents you from using throw? AFAIU, a local throw/catch of
an object of a fundamental type is no more expensive than a goto.

 Leo

---
[ 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                       ]

xleobx@qmailcomq.com wrote...
> Chris Newton <chrisnewton@no.junk.please.btinternet.com> wrote:
>> Many of the functions I work with daily use nested loops as part of
>> some mathematical algorithm. If we find the information we need
>> early, it is appropriate to break out of as many loops as possible
>> immediately. Currently, there is no construct in C++ that
>> represents this concept, although it is a common action in
>> practice.
>
> What prevents you from using throw? AFAIU, a local throw/catch of
> an object of a fundamental type is no more expensive than a goto.

I have several reservations about using throw instead. Starting with the
most significant...

1. It doesn't represent the required concept clearly.
2. It suggests an exceptional condition; escaping is routine.
3. It could take control arbitrarily far out...
4. ...with no warning if the exception *isn't* caught locally.
5. Your efficiency claim relies on a decent optimiser.

The major problem is the readability one, IMHO. I want a construct that
represents the idea of escaping from within nested loops to a specific
level within the nesting structure. This is what the algorithms I work
with do, how they fundamentally work.

Currently, I can do that with a single loop using break or continue, but
to do it with multiple loops currently requires some generic facility
(goto, throw, return, whatever) and that harms readability and
maintainability. To me, allowing this only in a special case seems
needlessly restrictive.

Regards,
Chris

---
[ 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 wrote...
> :-) But in the intervening 3 years we have started to draft changes and
> priorities.

I'm not questioning the fact that priorities must be assigned when
considering any proposed changes. I'm just suggesting that this change
is worth considering.

> No but the answer is very simple, draft a proposal including text for
> the next Standard and submit it to WG21's evolution group. If it is
> indeed as trivial as you suggest then it will not take you very long to
> do so. Of course the compiler implementors may then have something to
> say about it.

My idea is indeed almost trivial; that's why I can't understand the
problem you seem to have with it. Wording for the standard could be
modelled on the current standard's descriptions of jump statements. In
fact, the current behaviour of continue is even defined in terms of
equivalence to goto statements!

How does one go about submitting a suggestion for consideration? Would
it suffice to start a thread here, giving a description of the proposed
change, the motivation for it, and some suggested amendments to the
standard to implement the change?

I would be amazed if any compiler implementor had a technical problem
with implementing this. They already need all the necessary mechanics to
support the existing jump statements anyway.

Regards,
Chris

---
[ 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@robinton.demon.co.uk> wrote in message
news:TjKB8sARQHG$EwEb@robinton.demon.co.uk...

> Personally I am against it would just help bad programmers to write even
> worse code.

IMHO a language design shall just dismiss the 'bad and ignorant programmer'
issue.  At least a language on the C/C++ level definitely.  A bad programmer
can make uncountable many problems using UB already, break, goto and similar
stuff is just a teardrop in the ocean.
[Also, those bad programmers will likely not even know about the new
feature, they aren't bad for no reason are they? ;-]

The important thing is to support the good programmers, those willing to
write good and even better code.    And the labeled form of break/continue
we know in (eg. ) java is something that
- doesn't break existing code
- is almost trivial to implement
- gives way to write more expressive and safe code
- introduce no new way to shoot yourself in the foot

Guess you'd agree, break/continue, if put in the language at all, should
have been made that way from the beginning.   [especially with break
overloaded for use in switch.]

It's better to fix late than never.

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@robinton.demon.co.uk (Francis Glassborow) writes:

> In article <86r84mixl9.fsf@Zorthluthik.local.bar>, llewelly
> <llewelly.at@xmission.dot.com> writes
>>It's worth pointing out that the Go To Dijkstra orginally reviled is
>>    not the goto that C++ has. Dijkstra was attacking a goto that
>>    could goto any point in the program. C++ goto is bounded to the
>>    scope of the function. Given decently small functions, the goto
>>    and its target will be simultaneously visible. So IMO Dijkstra's
>>    primary argument against Go To does not apply to C++ goto, unless
>>    people are writing functions that are much too long anyway.
>
> I think you are mistaken

Why do you say this?

(I'm willing to believe I'm mistaken, but I'd like to know why you
    think so, and what particular parts of my paragraph you consider
    mistaken. )

> and Pascal has a global goto (and it is
> difficult to write large applications without such a mechanism, be it
> called goto, throw or whatever.
[snip]

There are large C programs that do not use longjmp (but do use goto),
    and there are large C++ programs that do not use exceptions. (In
    fact, most of C programs I've worked on have made no use of
    longjmp.)

---
[ 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                       ]

MJ wrote:
> For jumping _behind_ multiple loops there is already the 'goto'.

Since that is equally true of the existing 'break' statement,
your observation is irrelevant.

---
[ 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 in message news:<4upQa.8483$Y92.3354@nwrdny01.gnilink.net>...
> Jeff Petersen wrote:
> > a multi-level break
>
> We have had this discussion many times before.
> The correct way to do this would be to adopt Ada's style -
>
>      label: for (...) {
>                 while (...) {
>                     switch (...) {
>                         { break label; }
>
> 'break label;' or 'continue label' would take the specified
> action in the loop labeled with the designated label. This
> syntax is completely backwards compatible with C++ and C.

What do you think about this: If it were allowed to write 'break for;'
or 'continue for;' then it wouldn't be necessary to declare the label.

Also consider the following example:

  while (...) {
    switch (...) {
      case 1:   continue;
      case 2:   break;
      ...
    }
  }

In the above example 'continue' refers to the outer 'while', whereas
'break' just leaves the switch - unlike in the following examples:

  while (...) {
    switch (...) {
      case 1:   continue while;
      case 2:   break    while;
      ...
    }
  }

  while (...) {
    switch (...) {
      case 1:   continue switch;
      case 2:   break    switch;
      ...
    }
  }



Michael

---
[ 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                       ]

MJ wrote:
> What do you think about this: If it were allowed to write 'break for;'
> or 'continue for;' then it wouldn't be necessary to declare the label.

I think that it's a terrible idea. Specifying the label lets
you see, without ambiguity, where the statement will take you.
Not to mention that your way fails if we want to break out of
two for loops.

---
[ 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 <423c153c.0307170002.70247796@posting.google.com>, MJ
<c141592653589@hotmail.com> writes
>What do you think about this: If it were allowed to write 'break for;'
>or 'continue for;' then it wouldn't be necessary to declare the label.

Personally I am against it would just help bad programmers to write even
worse code.


--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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 in message news:<1058561253.379853@master.nyc.kbcfp.com>...
> MJ wrote:
> > What do you think about this: If it were allowed to write 'break for;'
> > or 'continue for;' then it wouldn't be necessary to declare the label.
>
> I think that it's a terrible idea. Specifying the label lets
> you see, without ambiguity, where the statement will take you.

For jumping _behind_ multiple loops there is already the 'goto'.

But for a jump to the beginning of a 'for' without passing the
initialization part again, the syntax you proposed would be useful.
But as it is rather equivalent to a 'continue', I suggest to allow
such backward jumps only together with the keyword 'continue'.


Michael

---
[ 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                       ]

pinzo@correo.nu (Bobo) writes:

> qrczak@knm.org.pl ("Marcin 'Qrczak' Kowalczyk") wrote in message news:<1434853.Qi1R8CJW5b@qrnik.knm.org.pl>...
>> Jeff Petersen wrote:
>>
>> > (short of doing a goto, which would suck).
>>
>> Why? IMHO goto is more readable than break N. You don't have to count loops
>> and switches, just look where the label is defined.
>>
>
> I wish programmers wouldn't have so many prejudices about goto. And
> all comes from books and teachers that advice not to use it at all.
>
> I think goto still has many uses.

It's worth pointing out that the Go To Dijkstra orginally reviled is
    not the goto that C++ has. Dijkstra was attacking a goto that
    could goto any point in the program. C++ goto is bounded to the
    scope of the function. Given decently small functions, the goto
    and its target will be simultaneously visible. So IMO Dijkstra's
    primary argument against Go To does not apply to C++ goto, unless
    people are writing functions that are much too long anyway.

(C++ goto is also not allowed to leap over the begining xor the end of
    an object's lifetime.)

---
[ 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 <86r84mixl9.fsf@Zorthluthik.local.bar>, llewelly
<llewelly.at@xmission.dot.com> writes
>It's worth pointing out that the Go To Dijkstra orginally reviled is
>    not the goto that C++ has. Dijkstra was attacking a goto that
>    could goto any point in the program. C++ goto is bounded to the
>    scope of the function. Given decently small functions, the goto
>    and its target will be simultaneously visible. So IMO Dijkstra's
>    primary argument against Go To does not apply to C++ goto, unless
>    people are writing functions that are much too long anyway.

I think you are mistaken and Pascal has a global goto (and it is
difficult to write large applications without such a mechanism, be it
called goto, throw or whatever.



--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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                       ]

>It makes very little difference how you break out of several levels at
>once you should be looking more closely at the design. At least we have
>a good motive for doing so with the current break (which some people
>would like to see removed:)

This is slightly off the current topic, but break is very  useful for
test-in-the-middle style of loops .  If break were deprecated, is
there any proposal to add such a construct?

e.g. such loops can currently be coded either

a)

// not nice due to subtle use of comma
while( loop first part, condition )
{
 loop second part
}

or b)

// using break, I think this is pretty clear
while( true )
{
 loop first part

 if( end condition )
  break;

 loop second part
}

or c)

// error prone repetition of code
loop first part

while( condition )
{
 loop second part,
 repeated loop first part
}

Matt

---
[ 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                       ]

Was just poking around slashdot and saw the link they had to the latest
proposal for the C++ language.  What I have always wished the language to
have is a multi-level break.  The existing keyword could handle it easily
enough, and it would allow for more efficient code.  For example:

-------------------------------------------------------
extern int array[100][100];
bool found = false;
for (int i = 0; i < 100; i++)
{
    for (int j = 0; j < 100; j++)
    {
        if (array[i][j] == 10)
        {
            found = true;
            break 2;    // break out two levels
        }
    }

    // some code here we do not want to execute when found perhaps
}

printf("found = %d\n", found);
--------------------------------------------------------

Needing this in switch statements is even more common:

--------------------------------------------------------
switch(value)
{
    case 1:
    {
        for (int i = 0; i < 100; i++)
        {
            if (array[i] == 7)
                break 2;
        }
        printf("not found, aborting");
        return;
    }
}
printf("continuing work");
--------------------------------------------------------

Currently, you have to set flag variables and check them after the first
break has occurred.  This is unnecessary overhead as the code-logic already
knows what it wants to do, the language syntax just doesn't allow it (short
of doing a goto, which would suck).  Obviously, you could break as many
levels as you want, and the compiler would produce errors as appropriate if
you tried to break too far.



---
[ 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                       ]

Jeff Petersen wrote:

> (short of doing a goto, which would suck).

Why? IMHO goto is more readable than break N. You don't have to count loops
and switches, just look where the label is defined.

--
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

---
[ 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                       ]

qrczak@knm.org.pl ("Marcin 'Qrczak' Kowalczyk") wrote in message news:<1434853.Qi1R8CJW5b@qrnik.knm.org.pl>...
> Jeff Petersen wrote:
>
> > (short of doing a goto, which would suck).
>
> Why? IMHO goto is more readable than break N. You don't have to count loops
> and switches, just look where the label is defined.
>

I wish programmers wouldn't have so many prejudices about goto. And
all comes from books and teachers that advice not to use it at all.

I think goto still has many uses.

Regard.
Bobo.

---
"When you fully understand the reason for a rule, you are ready to
break 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                       ]

Jeff Petersen wrote:
> a multi-level break

We have had this discussion many times before.
The correct way to do this would be to adopt Ada's style -

     label: for (...) {
                while (...) {
                    switch (...) {
                        { break label; }

'break label;' or 'continue label' would take the specified
action in the loop labeled with the designated label. This
syntax is completely backwards compatible with C++ and C.

Using 'break n;' is bad because it causes errors if structural
changes in the code cause a different value to be needed for 'n'.
The proposal above is immune to 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                       ]

In article <2iaQa.113345$98.4186887@twister.socal.rr.com>, Jeff Petersen
<jpetersen@san.rr.com> writes
>Was just poking around slashdot and saw the link they had to the latest
>proposal for the C++ language.  What I have always wished the language to
>have is a multi-level break.  The existing keyword could handle it easily
>enough, and it would allow for more efficient code.  For example:

You mean make it even easier to write code with deeply nested
structures? Well why not also have a multilevel return :)

It makes very little difference how you break out of several levels at
once you should be looking more closely at the design. At least we have
a good motive for doing so with the current break (which some people
would like to see removed:)


--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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                       ]

break and goto - I don't think it is a good C++ solution.

may be exceptions?
all my modifications in your code surrounded by // { ttshternlib

remove all comments and you'll recieve pritty code.

extern int array[100][100];
bool found = false;
// { ttshternlib
    class MyException1 {}; //local class
    class MyException2 {}; //local class
// } ttshternlib

for (int i = 0; i < 100; i++)
{
    for (int j = 0; j < 100; j++)
    {
        if (array[i][j] == 10)
        {
            found = true;
//            break 2;  - you don't need it.
            throw MyException1();
        }
// { ttshternlib
        if(array[i][j]==100)
        {
            throw MyException2();
        }
// } ttshternlib

    }

// { ttshternlib - inside first "for" && outside second "for"
// put this catch in that place, you want to go out when array[i][j]==10.
catch(MyException1 &m)
{
    // some code here we do not want to execute when found perhaps
}

// } ttshternlib
}
// { ttshternlib - outside first "for"
// put this catch in that place, you want to go out when array[i][j]==100.
catch(MyException2 &m)
{
    // some code here we do not want to execute when found 100 in array
}

// } ttshternlib

You can use all possibilities of exceptions (f.e. passing objects or
messages there) - just think about of MyException;
When you use something like break 2, you make problems with code
modifications. F.e. you put one more "if" or "for". You should remember,
that somewhere you used break 2 and change it to break 3 - i think it is not
very comfortable.

""Jeff Petersen"" <jpetersen@san.rr.com>                      /
                           : news:2iaQa.113345$98.4186887@twister.socal.rr.com...
> Was just poking around slashdot and saw the link they had to the latest
> proposal for the C++ language.  What I have always wished the language to
> have is a multi-level break.  The existing keyword could handle it easily
> enough, and it would allow for more efficient code.  For example:
>
> -------------------------------------------------------
> extern int array[100][100];
> bool found = false;
> for (int i = 0; i < 100; i++)
> {
>     for (int j = 0; j < 100; j++)
>     {
>         if (array[i][j] == 10)
>         {
>             found = true;
>             break 2;    // break out two levels
>         }
>     }
>
>     // some code here we do not want to execute when found perhaps
> }
>
> printf("found = %d\n", found);
> --------------------------------------------------------
>
> Needing this in switch statements is even more common:
>
> --------------------------------------------------------
> switch(value)
> {
>     case 1:
>     {
>         for (int i = 0; i < 100; i++)
>         {
>             if (array[i] == 7)
>                 break 2;
>         }
>         printf("not found, aborting");
>         return;
>     }
> }
> printf("continuing work");
> --------------------------------------------------------
>
> Currently, you have to set flag variables and check them after the first
> break has occurred.  This is unnecessary overhead as the code-logic
already
> knows what it wants to do, the language syntax just doesn't allow it
(short
> of doing a goto, which would suck).  Obviously, you could break as many
> levels as you want, and the compiler would produce errors as appropriate
if
> you tried to break too far.
>
>
>
> ---
> [ 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                       ]
>


---
[ 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                       ]