Programming thread

[analrapist]

like what

I linked the article for a reason, Dumb Dude 43. It answers your question at length.

 

[canalCrab]

like what
imo the main use case for goto is breaking through multiple layers of nested loops, for everything else there's better options

something like

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.

My goodness, no. I cited the context of the paper: go to statements. This is Knuth firing back at Dijkstra's "Go To Considered Harmful", and is Knuth explaining that, no, GOTO commands are just fine, and shoehorning other control flow methods into the space where GOTO fits naturally is bad practice.

Some reading materials, because apparently people in this thread are illiterate.

https://archive.org/details/Structured_Programming__Dahl_Dijkstra_Hoare - Structured Programming by Dahl, Dijkstra, Hoare
https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pdf - go to Considered Harmful by Dijkstra
https://dl.acm.org/doi/epdf/10.1145/356635.356640 - Structured Programming with go to Statements by Knuth

Yeah I did a tardery. Don't drink and post.

 

[WielkiWapiesz2137]

honestly i believe if arrays werent a syntax sugar over a pointer but their own object/abstraction they would start at one, since in mathematics first element of something is denoted using a "1" not "0"
but it does make math a little bit wonky, for example taking a mod of something would require adding a one and such

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

 

[CrunkLord420]

Manage yourselves.

 

[ADHD Mate]

My goodness, no. I cited the context of the paper: go to statements. This is Knuth firing back at Dijkstra's "Go To Considered Harmful", and is Knuth explaining that, no, GOTO commands are just fine, and shoehorning other control flow methods into the space where GOTO fits naturally is bad practice.

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.

He taught them to use go t o
only in unusual special cases where i f and
w h i l e aren't right, b u t he found [78] t h a t
"A disturbingly large percentage of the
students ran into situations t h a t require
go to's, and sure enough, it was often because
w h i l e didn't work well to their plan, b u t
almost invariably because their plan was
poorly thought out." Because of arguments
like this, I ' d say we should, indeed, abolish
go t o from the high-level language, at least
as an experiment in training people to
formulate their abstractions more carefully.
This does have a beneficial effect on style,
although I would not make such a prohibi-
tion if the new language features described
above were not available. T h e question is
whether we should ban it, or educate against
i t ; should we a t t e m p t to legislate program
morality? In this case I vote for legislation,
with appropriate legal substitutes in place
of the former overwhelming temptations.

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.

 

[Rango Dango]

https://dl.acm.org/doi/epdf/10.1145/356635.356640 - Structured Programming with go to Statements by Knuth

its great to see people were calling things "literally 1984" even before the internet

Why even bother with array indices? Any decent language worth using has support for foreach.

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

thats how APL niggers actually genuinely unironically write c btw
except they wouldve called the macro "f" or "fe" if we're being generous

 

[DumbDude43]

something like

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.

this feels like the type of thing that raii was made to avoid

 

[Rango Dango]

this feels like the type of thing that raii was made to avoid

yeah
gcc also has the cleanup attribute as an extension which does exactly that

cleanup (cleanup_function)
This attribute applies to variables.

The cleanup attribute runs a function when the variable goesout of scope. This attribute can only be applied to auto functionscope variables; it may not be applied to parameters or variables with static storage duration. The function must take one parameter,a pointer to a type compatible with the variable. The return value of the function (if any) is ignored.

When multiple variables in the same scope have cleanupattributes, at exit from the scope their associated cleanup functionsare run in reverse order of definition (last defined, first cleanup).

https://gcc.gnu.org/onlinedocs/gcc-16.1.0/gcc/Common-Attributes.html

 

[canalCrab]

this feels like the type of thing that raii was made to avoid

Yeah, in most languages these days it isn't relevant. But in something like pure c, it does often make sense.

 

[analrapist]

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.

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.

 

[ADHD Mate]

"should be the last resort" is stretching what Knuth is saying here.

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.

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.

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.