- Joined
- Apr 11, 2023
I linked the article for a reason, Dumb Dude 43. It answers your question at length.
Programming thread
- Thread starter Splendid
- Start date
-
Want to keep track of this thread?
Accounts can bookmark posts, watch threads for updates, and jump back to where you stopped reading.
Create account
I linked the article for a reason, Dumb Dude 43. It answers your question at length.
- Joined
- Dec 13, 2022
something like
Code:
setupcode1()
if (somethinggowrong)
goto td1;
setupcode2()
if (somethinggowrong)
goto td2;
setupcode3()
if (somethinggowrong)
goto td3;
setupcode4()
if (somethinggowrong)
goto td4;
dostuff()
td4:
teardowncode4()
td3:
teardowncode3()
td2:
teardowncode2()
td1:
teardowncode1()Can be useful for handling cleanup code.
Yeah I did a tardery. Don't drink and post.
- Joined
- Nov 10, 2024
If you think that mathematicians keep a standard for denoting first element you are mistaken. Infact it is even less standarized than in programing as most often it is whatever is most convinent
- Joined
- Jul 22, 2017
Manage yourselves.
- Joined
- Sep 11, 2024
I think we read different papers. Because Knuth is stating quite clearly that goto should be the last resort for when higher level control flows do not suffice. And even then the first question should be whether you are thinking about problem in right manner.
Other than that recursion elimination is solved by tail call optimization nowadays.
Coroutines can be easily implemented as language feature.
I really don't believe there is much use of goto nowadays, espcially true goto, which would be longjump in C.
- Joined
- Mar 4, 2023
its great to see people were calling things "literally 1984" even before the internet
thats how APL niggers actually genuinely unironically write c btwWhy even bother with array indices? Any decent language worth using has support for foreach.
C:#include <stdio.h> #define foreach(e,a)for(__typeof__(*a)*e=a,*a##_last=(a+(sizeof(a)/sizeof(*a))-1);e<=a##_last;++e) int main(void) { int xs[]={1,2,3,4,5}; foreach(x,xs)*x=*x%2?*x*3+1:*x/2; foreach(x,xs)printf("%d%s",*x,x!=xs_last?", ":"\n"); }
This might look hideous, but this is next level memory management which saves multiple bytes of disk space by removing extranous whitespace and using minimal variable names. But I guess this sort of thing would probably go over the heads of a bunch of cave-dwelling webdevs who only know JavaScript...
except they wouldve called the macro "f" or "fe" if we're being generous
- Joined
- Sep 28, 2022
this feels like the type of thing that raii was made to avoid
- Joined
- Mar 4, 2023
yeah
gcc also has the cleanup attribute as an extension which does exactly that
gcc manual said:
- Joined
- Dec 13, 2022
Yeah, in most languages these days it isn't relevant. But in something like pure c, it does often make sense.
- Joined
- Apr 11, 2023
You're taking my comments out of context. Here is how the Conclusion begins.
Remember, this is a response to "GOTO Considered Harmful". My statement "GOTO commands are just fine" shouldn't be read as "GOTO commands are always fine", but more that "GOTO elimination" as a dogmatic belief is an instance of premature optimization.
"should be the last resort" is stretching what Knuth is saying here.
- Joined
- Sep 11, 2024
I think it's perfectly acceptable interpretation given modern context, especially given that he himself states that "new types of syntaxes are being developed".
Which is also my arguement, goto is replacement for missing language feature.
I don't think I would interpret what Knuth is saying as this. I honestly believe he has opposite intention from this text, especially if you read later part of his conclusion which talks about students.
In which yes goto is acceptable, but in many, and maybe most, cases it's not the best choice and often a result of insufficient care in designing of structure.
Also in the context of premature optimization in knuth paper refers to using goto as optimizing transformation. So I think you have it flipped.
Using goto early is premature optimization, but you might want to use it.
Private Tag Reporter
kiwifarms.net
- Joined
- Jul 7, 2024
Are there any real world cases for go to other than continuing from a deeply nested loop? I can't think of any in my experience, and this was a specific circumstance, usually nested loops are a code smell.
- Joined
- Sep 10, 2021
C conditional teardown/error handling.
- Joined
- Nov 21, 2020
But goto is almost the only control statement. Everything else is just syntactic sugar on top of goto.
If is just conditional goto. Function calls are push stuff on the stack then goto. Return is pop stuff off the stack and goto.
If is just conditional goto. Function calls are push stuff on the stack then goto. Return is pop stuff off the stack and goto.
Private Tag Reporter
kiwifarms.net
- Joined
- Jul 7, 2024
Well, all things considered, all programming is an abstraction over selection, sequence, and repetition, unconditional GOTO being sequence and conditional GOTO being selection/repetition; or rather, all you need is BEQ/JE/conditional jump and you're good to go; the unconditional jump is already a single layer of abstraction over the conditional jump where the operands are always true/equal.
However every layer of abstraction above this is meant to make the mental load of dealing with these things easier, even if it maps imperfectly to a cpu. Imperfect software that is done is better than perfect software that's never finished - and maintainable, finished software is even better.
Fat Camp Intern
kiwifarms.net
- Joined
- Aug 15, 2025
snotang
kiwifarms.net
- Joined
- Jul 29, 2024
It's a bit amusing to see people question why goto exists because it shows that they can't see how so much of modern software is contorted to avoid it. So much of software today is written in a manner that effectively obfuscates the control flow by replacing the good old program counter with lots of miscellaneous flags, values that double as flags (nullable values), etc. Control flow gets turned into a string or enum or boolean which gets tested again to get back to control flow.
If you really want to find the places where goto is necessary, look at places where you can't just use other jumps as exact replacements. Lots of procedures use "return" as a means of skipping code that would otherwise be executed, but what exactly it skips is inherently tied to the procedure it's contained in - if you've ever tried copy+pasting a helper procedure's contents into another, you quickly discover that it also skips the rest of the containing procedure. Unless, of course, you're using a half-decent language that permits nested procedures or even just Common Lisp's "block" and "return-from" forms.
Also, sometimes the use of structures instead of goto's is just a plain nuisance. For example, many languages maintain a statement/expression distinction and will only allow expressions in certain parts of the structure, such as the condition for "if" or, much worse, "while". Many a CS101 student has been baffled at the need to write
especially considering how much you need to repeat yourself as the code that needs to be evaluated immediately before each test of the condition grows in size. People will try to cope by trying to combine multiple expressions together, using assignments as expressions, etc, but you can't include control structures themselves in the condition, to say nothing of exception handling clauses or finally blocks. For example, suppose our CS101 student didn't have "input" and only had "getchar". He would need to write a getchar loop twice. Of course, he could factor it out into a separate procedure, but that procedure may not be general in the slightest, and it rules out accessing the enclosing scope, and it adds an indirection that anyone trying to follow the control flow will have to look up. All because of an arbitrary syntax decision.
By comparison, goto is freedom:
The smart-aleck will look at this and notice that the same can actually be achieved using a while loop like so:
Which is functionally the same thing, except letting the language create the labels and the goto at the bottom for you, at the cost of the language also creating a conditional branch that always fails (will typically be optimized out, but the cognitive overhead and eyesore remains).
Or consider the case of trying multiple nontrivial ways of getting something, then doing something complex with it. Normally the way of trying a bunch of alternatives is to write if ... else if ... else if ... and so on, in sequence, but nothing nontrivial can really go inside the test expression of the "if". So you end up writing something like
But that's terrible, so you accept the pain of repeatedly checking "succeeded" even when it's already known to be true:
You see how we're encoding control flow in an extra flag that has to keep its value across all these attempts now instead of the program counter as God intended? Meanwhile with goto it's as simple as
Of course, the truly skilled at coping with an insistence on avoiding gotos will factor out all the "acquire" parts into a separate procedure so that they can use "return" to skip over all the remaining methods on success. Better yet, they might add a do...while(0) so that they can use "break" to skip over all the remaining methods on success.
Basically, when things get complex, programmers often reach for "return" or "break" or "continue", not because they want to return a value or explicitly need a conditional loop, but because they need "goto" but have been told "goto" is bad (or, worse, their language doesn't have it). This is the same sort of abstraction inversion that gives us things like RAII-instead-of-finally-blocks in C++ or object-with-no-fields-and-a-single-method-instead-of-function-pointer in Java. It's niggerlicious and I cannot take any language that refuses to have gotos (or an explicit equivalent such as tail calls) seriously.
If you really want to find the places where goto is necessary, look at places where you can't just use other jumps as exact replacements. Lots of procedures use "return" as a means of skipping code that would otherwise be executed, but what exactly it skips is inherently tied to the procedure it's contained in - if you've ever tried copy+pasting a helper procedure's contents into another, you quickly discover that it also skips the rest of the containing procedure. Unless, of course, you're using a half-decent language that permits nested procedures or even just Common Lisp's "block" and "return-from" forms.
Also, sometimes the use of structures instead of goto's is just a plain nuisance. For example, many languages maintain a statement/expression distinction and will only allow expressions in certain parts of the structure, such as the condition for "if" or, much worse, "while". Many a CS101 student has been baffled at the need to write
Python:
foo = input()
while not len(foo) == 0:
#... do something ...
foo = input()especially considering how much you need to repeat yourself as the code that needs to be evaluated immediately before each test of the condition grows in size. People will try to cope by trying to combine multiple expressions together, using assignments as expressions, etc, but you can't include control structures themselves in the condition, to say nothing of exception handling clauses or finally blocks. For example, suppose our CS101 student didn't have "input" and only had "getchar". He would need to write a getchar loop twice. Of course, he could factor it out into a separate procedure, but that procedure may not be general in the slightest, and it rules out accessing the enclosing scope, and it adds an indirection that anyone trying to follow the control flow will have to look up. All because of an arbitrary syntax decision.
By comparison, goto is freedom:
C-like:
loop_start:
foo = input();
if (len(foo) == 0) goto loop_end;
/* ... do something ... */
goto loop_start
loop_end:The smart-aleck will look at this and notice that the same can actually be achieved using a while loop like so:
C-like:
while(1)
{
foo = input();
if (len(foo) == 0) break;
/* ... do something ...*/
}Which is functionally the same thing, except letting the language create the labels and the goto at the bottom for you, at the cost of the language also creating a conditional branch that always fails (will typically be optimized out, but the cognitive overhead and eyesore remains).
Or consider the case of trying multiple nontrivial ways of getting something, then doing something complex with it. Normally the way of trying a bunch of alternatives is to write if ... else if ... else if ... and so on, in sequence, but nothing nontrivial can really go inside the test expression of the "if". So you end up writing something like
C-like:
/* Try to acquire using method 1 */
if (!succeeded)
{
/* Try to acquire using method 2 */
if (!succeeded)
{
/* Try to acquire using method 3, and so on... */
}
}
/* Complex usage of thing */But that's terrible, so you accept the pain of repeatedly checking "succeeded" even when it's already known to be true:
C-like:
/* Try to acquire using method 1 */
if (!succeeded)
{
/* Try to acquire using method 2 */
}
if (!succeeded)
{
/* Try to acquire using method 3, and so on... */
}
/* ... */
/* Complex use of thing acquired */You see how we're encoding control flow in an extra flag that has to keep its value across all these attempts now instead of the program counter as God intended? Meanwhile with goto it's as simple as
C-like:
/* Attempt to acquire using method 1 */
if (succeeded) goto use;
/* Attempt to acquire using method 2 */
if (succeeded) goto use;
/* Attempt to acquire using method 3, and so on */
if (succeeded) goto use;
/* ... */
use:
/* Complex use of acquired thing */Of course, the truly skilled at coping with an insistence on avoiding gotos will factor out all the "acquire" parts into a separate procedure so that they can use "return" to skip over all the remaining methods on success. Better yet, they might add a do...while(0) so that they can use "break" to skip over all the remaining methods on success.
Basically, when things get complex, programmers often reach for "return" or "break" or "continue", not because they want to return a value or explicitly need a conditional loop, but because they need "goto" but have been told "goto" is bad (or, worse, their language doesn't have it). This is the same sort of abstraction inversion that gives us things like RAII-instead-of-finally-blocks in C++ or object-with-no-fields-and-a-single-method-instead-of-function-pointer in Java. It's niggerlicious and I cannot take any language that refuses to have gotos (or an explicit equivalent such as tail calls) seriously.
Unimaginative Username
kiwifarms.net
- Joined
- May 27, 2025
I really don't like RAII in C++ because it hides acquisition of scarce resources by making them look like normal variable declarations. Since
using can't currently be followed by a left parenthesis in legal C++ code, I suggest that a new statement of the form using (decl1; decl2; ...) statement be introduced, where all the declarations have types that have been declared with a new [[resource]] attribute or are locally declared as having a new [[large]] attribute. This way, it would be clear that there's more going on that a usual local variable.As it is, if you have code like:
Code:
class Lock {
Lock(Mutex *m) { ... } // acquire mutex
~Lock() { ... } // release mutex
}
...
if (...) {
Lock lock(some_mutex);
...
} else {
std::vector<T> vec(N); // allocate ~5% of total system memory
...
}You could make it look like this:
Code:
class [[resource]] Lock { // now legal in using (...) statements and a warning when used elsewhere
....
}
...
if (...) {
using (Lock lock(some_mutex)) {
...
}
} else {
using ([[large]] std::vector<T> vec(N)) {
....
}
}As it is, it's tempting to add more code to a block that contains an RAII variable and unnecessarily extend the amount of time that a scarce resource is held, since it's syntactically identical to a normal, non-RAII block, and I think a new explicit syntax would help.
Agreed, but only if they adopt full Icon semantics for arrays, where the indices refer to the gaps between elements, identify the element to their immediate right, and run in both directions: so a[1] is the first element of a, a[-1] is the last element of a, and a[2:0] is a slice of a containing everything but the first element (i.e., everything from the position between the first and second elements and the position immediately following the end of the array).
Last edited:
- Joined
- Sep 28, 2022
i think arrays should take indices that are unicode strings
arr[
] = 60;
arr[
] = 7;
int i = [arr[] + arr[
];
cout << i; //67
arr[
] = 60;arr[
] = 7;int i = [arr[
] + arr[
cout << i; //67
Goose the Redeemer
kiwifarms.net
- Joined
- Apr 16, 2024
goto? Where? Why? return, break, and continue, are not just synonyms for goto, they have extra semantic meaning. I don't have to look for the label or assume the programmers intention. Goto has a bad image because most of the people definding it are midwits. RAII (and defer) are much better solutions to the only problem that goto actually solves.I know ":=" is relatively new in python, but C has always had the same construct.
Python:
def get_next_line():
# add linux support (^D)
try:
line = input()
except EOFError:
return None
# empty string is falsey, but maybe you want it to be explicit?
if len(line) == 0:
return False
return line
while line := get_next_line():
print(line)C can do that, as long as you use single characters. I was having trouble with emojis, I hope the cursed array access makes up for it.i think arrays should take indices that are unicode strings
arr[
arr[
int i = [arr[];
cout << i; //67
chars are just ints, which are (de facto) signed 32 bit, big enough for any unicode character but you might have trouble with negative indices, depending on the emoji.
C:
#include <stdio.h>
#include <stdlib.h>
int main(void) {
int *x = malloc('€');
x['['] = 34,
x[']'] = 35;
printf("%u\n", '['[x] + ']'[x]);
}(apparently I'm not the only one with emoji problems)
