|
Is goto dead?
If you designed your "dream language", would it have goto operator? And why?
Mine certaintly would. Although I feel a need for it maybe once or twice a year...
Egor Shipovalov
Saturday, February 7, 2004
I think you can get all the effects of goto with something akin to an exception. I believe PERL 6 has something like this in it.
Mostly gotos are used to escape from large nested loops (a bad idea, in of itself) and there are probably better ways to structure such a construct.
Almost Anonymous
Saturday, February 7, 2004
Perl already has goto. It also has redo which can be used to jump to the beginning of a block.
Anonymous
Saturday, February 7, 2004
Perl has all kinds of goto's, including computed and non-local ones, plus a few other control constructs you won't find anywhere else.
What I'm wondering about is how many experienced developers consider goto a worthwile feature and use it, at least sparingly...
Egor Shipovalov
Saturday, February 7, 2004
It's useful for breaking out of an inner loop, or for jumping to a 'finalise' clause; in both cases an alternative is to put the nested loop in a subroutine, and use 'return' instead.
Christopher Wells
Saturday, February 7, 2004
I have no strong feeling against gotos, but even so I've *never* uesd one in 10+ years of writing C/C++. So I can't imagine *needing* it in my dream language.
Actually my dream language would have just one keyword:
DoExactlyWhatIWant_NotWhatISaid :)
sgf
Saturday, February 7, 2004
Goto is never necessary but it can make code much easier to read and maintain in a small set of situations, these are covered in Code Complete I think.
I would include goto. I like the Perl idea of distinguishing between forward and backwards gotos.
Goto is easy to abuse and thus I think a CS course discussing it should cover the small number of situations in which goto can be helpful and the alternatives for those who wish to not use goto.
Likewise, in a woodworking shop, a bandsaw should be available, but the carpenters should be well trained in how to avoid cutting their fingers off with it.
Dennis Atkins
Saturday, February 7, 2004
Like sjf, I haven't used a goto since the line numbered basic days. I also have never needed to use any tricks, like using flags, to get out of nested loops.
Almost Anonymous
Saturday, February 7, 2004
I use gotos in my C code for error-handling. The trick for keeping it clear is to do forward jumps only. Without goto, there's too many conditionals, along with repeated clean-up code, when handling errors, that it obscures the logic of the original code.
Programming in Python, I've never felt the need for a goto -- handling errors with exceptions is much cleaner.
scruffie
Saturday, February 7, 2004
Here and there someone in some committee decides that
some feature is dangerous and wipes it out of the language. Like pointers or the way switch works in C# or in
Pascal.
Personally, I hate goto, but I really wouldn't know how
to do anything without pointers and I like my switch to
share few cases together (but then I make a comment
like // no break here).
So keep goto, keep pointers keep everything, but tell
programmers that some stuff is dangerous or let them
learn by themselves.
VPC
Saturday, February 7, 2004
"goto" is great for crude emulation of exceptions in plain C. It is also sometimes useful for implementing inner loops of interpreters or VMs (use goto for each opcode to avoid function calls). But I'm not sure it's very useful beyond these things. Certainly there is no purpose for "goto" in higher-level languages.
Dan Maas
Saturday, February 7, 2004
The keyword for "goto" should be "uglyuglygoto" so programmers would have a bad feeling every time they use it.
Alex.ro
Saturday, February 7, 2004
Actually, the most useful statement for a new language would "comefrom". Very useful during debugging...
sgf
Saturday, February 7, 2004
Whether goto is dead or not depends on what programs you write. Goto is, and will always remain, extremely useful for "mathematical" algorithms where refactoring inner-loop code into small subroutines is both difficult (speaking names are hard to find, too many in/out parameters to pass) and undesirable for efficiency reasons. If you never write such code, as I understond most goto haters don't, you'll probably never need goto in a modern language.
Chris Nahr
Sunday, February 8, 2004
"The keyword for "goto" should be "uglyuglygoto" so programmers would have a bad feeling every time they use it."
Beautiful!
Comment of the week!
gwyn
Sunday, February 8, 2004
We need goto: the language should trust me to make the right decisions case-by-case, not force some committees' broad general decisions on me. If I use goto, it's on my conscious
Dream language? I used to think about that kind of think years ago, but as I ain't going to write a compiler, I live with what I got.
I reasonably happy with C++ despite it's many warts
I would like some additions, starting with an enhanced break statement that can apply to a higher level (e.g an outer for loop which must presumably be labelled in some way) than the most nested
e.g.
for ( int y = ...etc.... ) as loopy
{
for ( int x = ...etc.... ) as loopx
{
switch ( z[x][y] )
{
// etc...
case whatever:
break loopx ; // would break to point 1
case soomething:
break loopy ; // would break to point 2
}
} // for x
// <--- point 1
} // for y
// <--- point 2
S.Tanna
Sunday, February 8, 2004
Hmm, I think the obvious criticism would be this: if you're going to jump across flow control constructs, and you have to use labels anyway, then you might as well use goto.
Chris Nahr
Sunday, February 8, 2004
S.Tanna, Perl has such a feature. It allows you to break out from, redo or continue any particular labeled loop you're in. While it does come in handy sometimes, those cases are fairly rare and non-trivial.
Chris, goto knows nothing about loop counters or iterators, but Perl's labeled constructs do.
Egor Shipovalov
Sunday, February 8, 2004
EWD1308
http://www.cs.utexas.edu/users/EWD/
Gives a short introduction to EWDs paper to ACM about the gotostatement.
The EWD papers have a lot of interesting reading, and it shows that the problems comming up in todays programming, has often been worked on and discussed already in the 1960:ies. I have personally seen code with floatingpoint number problems that were solved a long time ago and with papers online explaining how to avoid the problems. The Mhz speed may have changed but many of the rules are the same.
"Finally a short story for the record. In 1968, the Communications of the ACM published a text of mine under the title "The goto statement considered harmful", which in later years would be most frequently referenced, regrettably, however, often by authors who had seen no more of it than its title, which became a cornerstone of my fame by becoming a template: we would see all sorts of articles under the title "X considered harmful" for almost any X, including one titled "Dijkstra considered harmful". But what had happened? I had submitted a paper under the title "A case against the goto statement", which, in order to speed up its publication, the editor had changed into a "letter to the Editor", and in the process he had given it a new title of his own invention! The editor was Niklaus Wirth."
The goto statement considered harmful
http://www.acm.org/classics/oct95/
Do anyone else have any good resources for computer science papers ? Yes, I know about http://citeseer.nj.nec.com/
Fredrik Svensson
Sunday, February 8, 2004
> S.Tanna, Perl has such a feature. It allows you to break out from, redo or continue any particular labeled loop you're in. While it does come in handy sometimes, those cases are fairly rare and non-trivial.
The reason you need the "break from for" in C/C++ is because break is used for more than one purpose in C++
Consider
for ( int x = 0 ; x < 10 ; x++ )
{
if ( y[x] == somevalue )
{
break ;
}
// point 1
}
// point 2
vs
for ( int x = 0 ; x < 10 ; x++ )
{
switch (y[x])
{
case whatever:
break ;
}
// point 1
}
// point 2
In the first example, we break to point 2, in the second example we break to point 1.
What's more in the 2nd example it's not even possible to get to point 2 without extra coding or a goto -- merely because we happen to be using a switch instead of a if- statement.
If the designers of C had used a different word for switch (break-switch vs break-for), then it would solve 99% of these type of issues.
I agree, the other 1% (breaking more than one level of loop nesting), is rare
As for why not use a goto for this type of break?
Well why not use a goto for any type of break? Compare Pascal... continue/break in C are very much like goto's -- just a sugared up version. I don't mind a bit of sweetener :-)
S.Tanna
Sunday, February 8, 2004
> Hmm, I think the obvious criticism would be this: if you're going to jump across flow control constructs, and you have to use labels anyway, then you might as well use goto.
Because the reader knows that you are breaking out of a loop or whatever, when he says break
If a reader sees goto, he has to examine the destination to know what you are doing
S.Tanna
Sunday, February 8, 2004
I guess C# is bringing it back into use :-)
I am learning C# after many years of Delphi and embedded C - I notice in C# the only way to 'fall-thru' in a case statement is explicitly 'goto' the required case. i.e.
switch(foo)
{
case 1:
// do something
goto case 2;
break;
case 2:
....
}
Johnny Moondog
Monday, February 9, 2004
"If a reader sees goto, he has to examine the destination to know what you are doing."
Okay, I was assuming that nobody would use goto's today in such a fashion (multiple goto's in huge functions) that spotting the jump points would be a problem. Most traditional cases are already taken care of by break, continue, return.
Johnny: That's true but you don't need the additional break after a "goto case" statement -- the "goto case" is already a valid case terminator, just like "return" or throwing an exception.
Chris Nahr
Monday, February 9, 2004
BOOL fancy_transaction() {
if(!step1()) goto unroll_step1;
if(!step2()) goto unroll_step2;
if(!step3()) goto unroll_step3;
return SUCCESS;
:unroll_step3:
unstep2();
:unroll_step2:
unstep1();
:unroll_step1:
return FAIL;
}
i like i
Monday, February 9, 2004
You are quite true Chris about the break being redundant - I tend to write them in subconciously due to years of conforming to MISRA and company coding guidelines :-)
Johnny Moondog
Monday, February 9, 2004
It wouldn't have goto, it would have last-call optimization, a subset of which is tail recursion.
Junkster
Monday, February 9, 2004
i like i:
How is that better than functions? (assuming you have a halfway decent optimizing compiler)
Richard P
Monday, February 9, 2004
S.Tanna -- all those contortions with a made-up switch statement, how is that better than a plain goto?
Alex.ro
Tuesday, February 10, 2004
I know someone will do better, but this is what I'd do about that code :
BOOL fancy_transaction() {
int s1_ok=0,s2_ok=0;
if( (s1_ok=step1()) && (s2_ok=step2()) && step3() )
return SUCCESS;
if (s2_ok) unstep2();
if (s1_ok) unstep1();
return FAIL;
}
Note: I am quite sure standard C uses shortcuts in boolean expressions and always evaluates expressions from left to right (so when step1 fails, step2 and step3 *are not* reached, and when step2 fails, step3 is not reached)
Ross
Tuesday, February 10, 2004
Ugh. If you're going that route, I'd just do this:
BOOL fancy_transaction() {
if( step1( ) ) {
if( step2( ) ) {
if( step3( ) ) {
return SUCCESS;
}
unstep2( );
}
unstep1( );
}
return FAIL;
}
Easier to read, blatantly obvious what it's doing, and robust in maintenance since it's easy to add or remove steps.
Chris Tavares
Tuesday, February 10, 2004
Of course, one could argue that the return in the middle of the function is really no different than a goto.
Chris Tavares
Tuesday, February 10, 2004
I knew! LOL I agree Chris Tavares' code is better (not unnecessary tricky, and cleaner)
Ross
Wednesday, February 11, 2004
 Recent Topics
Fog Creek Home
| 
