Re: goto considered helpful

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

On 13/12/2024 13:19, David Brown wrote:

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

 

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++.

 The lambda version needs closures from what I can see, although that might be optimised out.
 

Yes.  Whether the closure is "optimised out", or was never created in the first place (no closure ever needs to be generated when the captured variables are all still in their lifetime when the lambda is run) is a question of implementation detail - and not one that I can answer.

 

(I've also used C++ tuples for returning multiple values.

  From that 'inner' function presumably; the main one returns one value.
 

Yes.

>
I haven't compared to a multi-level break statement, because neither C nor C++ have such a feature (as yet).

 I've written a version in my syntax below, with some comments.
 

It's fairly obvious how your code is working (that's a complement, by the way).  "exit" seems a bit dramatic compared to "break", but perhaps that's just habit from C, Python and other programming languages.

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.

 Do you mean this line:
 

         return std::tuple(n, n, n);

 Because even without it, it seems to work for M=10 (when the break is commented out). That is, it gives the same result on versions that just fall off the end of the outer loop.

That is why I picked that return value - it keeps it the same for all the versions of the function.
However, in a real program, you would almost certainly want to treat this case differently - being forced to write something specific here is a good thing, and better than you get with a multi-level break. (Exactly how you treat this case would depend on the real code - it could be marked with "unreachable();", it could return a default value, it could return a canary value, it could throw a C++ exception, it could return a std::optional<> or std::expected<> or a C structure with similar functionality, or print an error message and exit the program.)

 

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'm saying that if you don't have the general feature, then the more limited one might be worth considering, as it will take care of most of the use-cases not covered by break.
 

If lambdas are not added to C, then a multi-level break of some sort would be useful to some people - I agree on that.

(My personal codebase is not expansive enough to definitely say intermediate breaks will be never needed, or very rarely. Others may use nested loops a lot more.)
 --------------------------
 fun test(int x, y, z)bool = sqr(x)+sqr(y) = sqr(z)
 func foo(int n)int =
     for x in 2..n do
         for y in 2..n do
             for z in 2..n do
                 exit all when test(x,y,z)
             od
         od
     od
      x*10000 + y*100 + z
end
 proc main=
     println foo(10)
end
--------------------------
 Notes:
 * Your version seems to convert from 1- to 0-based; I reversed that. But
   that might have been to inject some extra code outside the loops

It was merely to inject some extra code outside the loops - nothing more than that.

 * Despite what you say, such a example could easily just return from
   inside the loop. So the example is just to illustrate multi-level
   break

The point was to put the the handling of the x, y, z result /outside/ the loop, precisely to avoid a return from inside the loop.  Pretend it did something more than evaluate a simple arithmetic expression.

 * (If this is supposed to find Pythagorean triples, those loops could be
   shorter)
 

Nothing here is doing a particularly difficult job - the whole thing could have been replaced by "return 30405;", but that would not be very helpful!

* The program size in bytes is here half the size of your foo5() example
   in C++ (with other functions and cplusplus blocks removed). (288 vs
   570 bytes)

The size cannot sensibly be compared.

 * I tried your foo5 version in my dynamic language. There I found some
   scoping issues that I'd need to fix. Putting workarounds in, plus
   that extra return after the loops, made it much busier than my static
   version. That language of course runs the simple version too, and is
   somewhat shorter.