Re: goto considered helpful

On 13/12/2024 12:12, bart wrote:

On 13/12/2024 08:50, David Brown wrote:

On 12/12/2024 22:50, Keith Thompson wrote:

Michael S <already5chosen@yahoo.com> writes:

On Wed, 11 Dec 2024 17:27:53 -0800
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

bart <bc@freeuk.com> writes:
[...]

My experience of multi-level break is that there are two main
use-cases:
>
  * Used in the current loop only (not necessarily the innermost to
an observer). This is the most common
>
  * Used to exit the outermost loop
>
So to support these, named or even numbered loops are not
necessary. (Eg. I use 'exit' or 'exit all'.)

>
I would oppose a change to C that only applied to innermost and
outermost loops.  For one thing, I'm not aware of any other language
that does this (except perhaps your unnamed one).  For another,
it's easy enough to define a feature that handles any arbitrary
nesting levels, by applying names (labels) to loops.

>
The better solution is education.
Convince teachers in unis and colleges that goto is *not* considered
harmful for this particular use case. Convince them to teach that
attempts to avoid goto [for this particular use case] are really
considered harmful. If you don't believe in authority of yourself then
ask for help from somebody famous that share this view. I would guess
that nearly all famous C programmers share it.

>
Backward gotos tend to be dangerous.  Forward gotos are less so.
>
Dijkstras original "Go To Statement Considered Harmful" letter was
written in 1968, at a time when many languages didn't necessarily
have the structured control constructs we've come to expect since
then.  Using goto to implement a loop is almost always a bad idea,
but it's something that a modern C programmer probably wouldn't
even consider doing.
>
I agree that gotos have valid uses.
>
Here's an answer I wrote on Stack Exchange some years ago to the
question "Is using goto ever worthwhile?" :
https://softwareengineering.stackexchange.com/a/133523/33478
>
Quoting from that answer :
>
     The main use of a goto in a reasonably modern language (one that
     supports if/else and loops) is to simulate a control flow construct
     that's missing from the language.
>
I would support adding named loops and labeled exit/continue to
a future version of C.  I've used languages that have similar
features, and have found them very useful.  Given that C doesn't
have multi-level break, I tend to agree that a goto statement is a
reasonable way to simulate it, often better than the alternatives.
(It's important to use a meaningful label name.)  Similarly,
the C code in the Linux kernel makes extensive use of gotos for
error handling.
>
If C didn't have a break statement at all, it could be simulated
with goto.  If that were the case, I'd still favor adding a break
statement to the language.  I support adding labeled break statements
for the same reason.  Goto is not the root of all evil, but it's
worth some effort to avoid it when other constructs are clearer.
>

>
I personally have found "goto" in C to be useful on no more than a couple of occasions during my entire career.  I'd find a labelled "break;" statement somewhat more useful - but I think I can confidently say I would never want to use some kind of relative numbered "break 2;" or similar statement.  Such multi-level breaks would be far too rare in code for people to interpret "automatically" - many programmers would need to think hard about whether the number is from the outside in, or inside out, and starting from 0 or starting from 1.  A labelled break would be vastly clearer.
>
If I find I have such complicated loops and need to break out of them, I will sometimes use local boolean flags - that gives you a convenient place to give a name to the condition, and the compiler turns it all into "gotos" in the generated code.  Alternatively, the function can be split up - multi-level "break" from the inner loop is now just a "return" from the "inner" function.  This would be neater if C supported nested functions of some sort - perhaps a restricted form of lambdas. (For C, it would be natural to limit these to cases where there is never a closure object created.)
>

  Some people don't like ordinary break either. There you could also suggest using convoluted logic, or using a function instead But here 'break' would be clearly be simpler and easier.

I can only express my own opinion - if someone else doesn't like "break;", that's up to them.

 (I'd like to see a lambda example that is simpler than a two-level break or even a goto.)

<https://godbolt.org/z/7qWf966Er>
There is a simple three-level nested loop function with an "escape" from the inside loop, written in several different ways.  There is somewhat arbitrary calculations before and after the loops, so that the it can't just use a direct "return" from the middle of the loop - it needs some kind of multi-level break effect when "test(x, y, z)" passes.  The lambda version code is C++, since that has lambdas and C doesn't, but the rest can be compiled as C or C++.
(I've also used C++ tuples for returning multiple values.  I could have used a struct, but tuples are more convenient for this kind of thing.)
The generated code from gcc is all much the same for each function version - there are no significant overheads for any of the methods.
I haven't compared to a multi-level break statement, because neither C nor C++ have such a feature (as yet).
What you think is "simpler", is, of course, highly subjective.  I like the lambda version ("foo5") for various reasons.  All the variables are initialised in their declarations and (apart from the loop indexes) could be declared "const" - where possible, I prefer local variables to be initialised and unchanging as it makes the code easier to follow and easier to reason about.  The inner loop function is at the appropriate place in the code as a local function, unlike the C version "foo4".
The other big advantage of the "static inner function" version (valid C) and the lambda version (C++ only - though lambdas are being considered for C) is that it is immediately obvious when writing them that there is a huge difference between breaking out of the loops when the test passes, and falling off the end of the loops because the test never passes.  I've been lazy in this example, but you can't miss it - with the goto to break versions, it's easily forgotten.
int foo5(int m) {
     int n = m + 1;
     auto [x, y, z] = [n]{
         for (int x = 2; x < n; x++) {
             for (int y = 2; y < n; y++) {
                 for (int z = 2; z < n; z++) {
                     if (test(x, y, z)) return std::tuple(x, y, z);
                 }
             }
         }
         return std::tuple(n, n, n);
     }();
     return 10000 * x + 100 * y + z;
}

 I've had a quick look through my codebases (not C), and I couldn't see an example of a numbered break. All I could find was the equivalant of:
     break              # the vast majority
    break all
 The latter breaks out of the outermost loop.
 

So you have a feature (numbered breaks) in your language that you never use, but have been recommending here as a useful addition to C?
I can appreciate that "break out of all loops" would be the most commonly useful type of break beyond the standard "break out of the innermost loop".