Comment by politician
13 days ago
It would be ideal if Go would add support for computed goto, so that we could build direct threaded interpreters.
13 days ago
It would be ideal if Go would add support for computed goto, so that we could build direct threaded interpreters.
Is computed goto used for anything other than interpreter loops? Because if not, I would rather have a special "it looks like you're trying to implement an interpreter loop" case in the compiler than add new syntax.
Yes. Goto is useful for efficient control flow in many stateful algorithms.
I don't know that _efficient_ is the best word. If you use goto to force a particular control flow rather than a more constrained form of control flow (e.g. if), you make it harder for the optimiser to work; it can only make "as-if" changes, ones that mean the code that executes looks as if it's what you wrote.
The most efficient control flow is one that describes only what your algorithm needs, coupled with an optimiser that can exploit the particular flow you're describing.
Among the many things discovered by the author of https://blog.nelhage.com/post/cpython-tail-call/, Clang/LLVM was able to optimise the standard switch based interpreter loop as if it had been written with computed gotos.
1 reply →
Did you mean "assigned GOTO", not computed GOTO? Because that's just a switch list.
https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html
'computed goto' is used in gcc to mean the same as assigned goto in Fortran. The Fortran variation appears to have more restrictions than the gnuc one.
I may be dumb, but what is "goto *ptr;" useful for? Or &&foo.
4 replies →
I don't think "ideal" would be the exact word - I used to shudder at it in FORTRAN.
Go to goto, go!
hard no - goto is a feature for code generators, not anything meant for human use
I never understood this argument. Without RAII you can easily get screwed by resource leaks without goto when returning early. In this regard, using goto is expedient. How do C programmers avoid this problem without goto?
Attributes, mostly. Which have become so common that defer is very likely to be in the next C standard. [0]
[0] https://thephd.dev/c2y-the-defer-technical-specification-its...
Nested ifs are my preference:
Much shorter and more straightforward.
One-time loops with break also work if you're not doing the resource allocation in another loop:
Still simpler to follow than goto IMHO. Both these patterns work in other languages without goto too, e.g. Python.
1 reply →
Open a scope when you check resource acquisition passed, rather than the opposite (jump to the end of the function if it failed).
It can get quite hilly, which doesn't look great. It does have the advantage that each resource is explicitly only valid in a visible scope, and there's a marker at the end to denote the valid region of the resource is ending.
EDIT: you mentioned early return, this style forbids early return (at least, any early return after the first resource acquisition)
In this example couldn’t the go to cleanup instead be return cleanup_func where the same cleanup code was executed?
Maybe that is exactly the problem, stop using a language designed in 1970's that ignored on purpose the ecosystem outside Bell Labs, unless where it is unavoidable.
And in such case, the C compiler doesn't have a limit to write functions and better modularize their implementations.
Ah, but all those free() calls get tedious can be forgotten and mistyped
Can still be improved with a mix of macros and varargs functions.
Or if using language extensions is a thing, the various ways to do defer in C.
4 replies →
There are situations in practical code where goto is the only reasonable choice if you want to avoid spaghetti code. Absolutes have no place in software, you can find scenarios where almost every typically bad idea is actually a good idea.
It is a tool, not a religion.
Even Dijkstra was clear that he was only referring to unbridled gotos.