Goto statement, mostly regarding Fortran

fluidistic

Hey guys,
I've read that Borek (a member here) was told that the goto statement was "bad" during the 80's. I myself did some research on the Internet about that and it seems that:
1)Fortran used to have the goto statement up till Fortran 90.
2)It has been eradicated since Fortran 95.
3)In wikipedia one reads

The 1960s and 1970s saw computer scientists move away from GOTO statements in favor of the "structured programming" paradigm.

I'd like to know why it is considered as "bad" to use the goto statement, particularly in Fortran but I wouldn't mind if someone reply for another language.

And also, how would you modify this part of one of my codes:

Code:

98 write(*,*)"In order to solve the linear system, do you want to use Jacobi(1)'s method or Gauss-Seidel(2)'s one?"
read(*,*)p
if (p==1) then
call jacobi(n_max,n,tol)
else if (p==2) then
call gauss(n_max,n,tol)
else 
write(*,*)"Please choose a valid option"
goto 98
end if

It seems so intuitive and efficient that I'm really curious what's "bad" about it and what would be the "correct" version according to nowadays programmers.
Thanks a bunch in advance! (I'm really eager to know!)

jtbell

My experience with Fortran ended with the extended version of Fortran 77 that was available on VAX and Prime computers, so I'll use C++ for my two goto-less versions. This one most resembles your version:

Code:

cout << "In order to solve […]? ";
do
{
    cin >> p;
    if (p == 1)
        jacobi (n_max, n, tol);
    else if (p == 2)
        gauss (n_max, n, tol);
    else
        cout << "Please choose a valid option (1 or 2): ";
} while ( ! ((p == 1) || (p == 2)) )

I personally would use the following version, which separates asking for the choice from actually performing the choices:

Code:

// Find out which algorithm to use.

cout << "In order to solve […]? ";
cin >> p;
while ( ! ((p == 1) || (p == 2)) )
{
    cout << "Please choose a valid option (1 or 2): ";
    cin >> p;
}

// Perform the chosen algorithm.  At this point we are guaranteed
// that p is either 1 or 2.

if (p == 1)
    jacobi (n_max, n, tol);
else
    gauss (n_max, n, tol);

swartzism

Goto statements in any language make for hard to read code and are an inefficient way to do things. Your example of code is very simple and easy to follow, so it does not fall into the above category, but for example,

Code:

      do 110 i=1,2000
         if(a .ge. b(i)) then
            go to 110
         endif
         indx = i
         go to 112
 110  continue

      indx = 2000
 112  z = float(indx-2)*c + c*(a - b(indx-1))/(b(indx) - b(indx-1))

This is a very confusing snippet of code utilizing goto statements. Which is extremely hard to follow and see what is going on.

I like Serena

We like to call it "spaghetti".
You can compare it to a rope that has become entangled.
As you may know it takes a lot of skill and effort to discern how it is entangled.
And it is a lot of work to untangle it.

Mark44

Quote by fluidistic

Hey guys,
I've read that Borek (a member here) was told that the goto statement was "bad" during the 80's. I myself did some research on the Internet about that and it seems that:
1)Fortran used to have the goto statement up till Fortran 90.
2)It has been eradicated since Fortran 95.

I don't believe goto has been "eradicated" since Fortran 95. The wiki article on Fortran 95 (http://en.wikipedia.org/wiki/Fortran_language_features) says this:
"The simple GO TO label exists, but is usually avoided — in most cases, a more specific branching construct will accomplish the same logic with more clarity."

rcgldr

A previous and long thread about goto's. In some situations, for some programmers, they're better than the alternative:

http://www.physicsforums.com/showthread.php?t=308782

gb7nash

It's hard to follow and can get pretty insane if you have multiple goto's all over the place. Anyone trying to debug tons of goto's will probably throw their computer out the window.

I like Serena

Quote by rcgldr

A previous and long thread about goto's. In some situations, for some programmers, they're better than the alternative:

http://www.physicsforums.com/showthread.php?t=308782

Let's not make such a long spaghetti thread here!

(I think there are goto's in it!

)

Hurkyl

One of the ideals of writing a program is that it should be self-documenting. A WHILE loop or a FOR loop are somewhat more descriptive than the equivalent construct built out of GOTO and IF-THEN statements.

Most commonly needed ways to control the flow of your program can be more concisely and clearly described via methods without invoking a GOTO statement. Many of the exceptions can be rearranged into a simpler program that doesn't use GOTO.

A lot of the GOTO hate is unwarranted, however. It's like the pirates vs global warming thing -- once upon a time GOTO was more or less all that was available, and people frequently wrote spaghetti^* code. So people blamed GOTO as actually being the cause, rather than the lack of options simply being correlated with programming attitudes of the time.

And, of course, there is also some naivety of the form "if we forbid GOTO, then people can't write spaghetti code!" which motivates some more of the GOTO hate.

Sometimes, GOTO hate is taken to an extreme, turning into hate for BREAK, CONTINUE, some uses of exception handling, or even a RETURN that appears someplace other than the very last line of a function.

*: Spaghetti code is so named because it's not clear (or even impossible!) to tell what is happening in the program without paying very careful attention to the thread of execution as it winds through the program. Also, there is the subsequent problem that it is very difficult to modify the program.

I like Serena

For myself, I agree with your point of view on goto and other forms.

However, having worked in projects where lots of different junior programmers come along, I found it is best to keep the programming style rules simple and predictable.

fluidistic

Thanks a lot to you all guys for the insights. Too much to answer for me!
First, sorry I hadn't searched in PF about goto. The mentioned thread that rcgldr posted seems very interesting.
About jtbell: Too bad I don't know C++ at all. But looking carefully at your code I can understand some stuff. However I do not see where is the "goto" statement in your first code.
To Mark44, thanks for the link. Actually what I read on Fortran page seems different? Or my English is too bad so that I misunderstand. What do you say:

Quote by Wikipedia

Several features noted in Fortran 90 to be deprecated were removed from Fortran 95:

DO statements using REAL and DOUBLE PRECISION variables
Branching to an END IF statement from outside its block
PAUSE statement
ASSIGN and assigned GOTO statement, and assigned format specifiers
H edit descriptor.

What do you understand from this? What I understand is that Fortran 95 doesn't have the "goto" statement anymore.

And swartizm, here is your code:

Code:

 do 110 i=1,2000
         if(a .ge. b(i)) then
            go to 110
         endif
         indx = i
         go to 112
 110  continue

      indx = 2000
 112  z = float(indx-2)*c + c*(a - b(indx-1))/(b(indx) - b(indx-1))

Would that even compile?! I mean, I never seen

Code:

do 110 i=1,2000

.
Did you mean

Code:

do i=110,2000

?

Mark44

What they removed from Fortran 95 was the assigned GOTO statement, which is described here - http://www.nsc.liu.se/~boein/f77to90/a2.html. That's not the same as the plain old GOTO statement.

The code that swarzism provided is an older style (Fortran 77?). The line number in the do statement refers to the line number of a continue statement.

Code:

do 110 i = 1, 2000
! some stuff
110 continue

The code in the preceding sample is equivalent to this code:

Code:

do i = 1, 2000
! some stuff
end do

fluidistic

Quote by Mark44

What they removed from Fortran 95 was the assigned GOTO statement, which is described here - http://www.nsc.liu.se/~boein/f77to90/a2.html. That's not the same as the plain old GOTO statement.

The code that swarzism provided is an older style (Fortran 77?). The line number in the do statement refers to the line number of a continue statement.

Code:

do 110 i = 1, 2000
! some stuff
110 continue

The code in the preceding sample is equivalent to this code:

Code:

do i = 1, 2000
! some stuff
end do

Ah thanks, now I understand swartizm's code.
About assigned goto statement, I'm not understanding the difference with the goto statement.
For instance,

? GOTO (snr1, snr2, snr3), integer_expression
- conditional GOTO statement. If the integer
expression is 1, 2 or 3, execution jumps to
statement number snr1, snr2 or snr3 (an arbitrary
number of statement numbers snr are permitted).

??GOTO statement_number_variable, (snr1, snr2, snr3)
- an assigned GOTO statement, jumps to the statement
number that equals the statement
number variable (an arbitrary number of
statement numbers snr are permitted).

For the first goto, I could write

Code:

goto (100, 156, 200), 2

. It would be the same as if I write

Code:

goto 156

.
For the second, if I understand well, I could write

Code:

goto 354 (15, 98, 354)

and it's the same as if I write

Code:

goto 354

.
The first looks like allowed in Fortran 95 while the second not.
Hmm I'm sure I don't get it.

chiro

Quote by fluidistic

Hey guys,
It seems so intuitive and efficient that I'm really curious what's "bad" about it and what would be the "correct" version according to nowadays programmers.
Thanks a bunch in advance! (I'm really eager to know!)

That's the thing. A goto statement is non intuitive for most programmers.

A goto is just a form of flow-control that does not have context information. Let me explain what I mean.

When you write branching code like an if statement: you can easily read the branching conditions in the if statement and see exactly what it is doing in terms of the criteria of the branch and change in flow control. You see what variables affect the change and you can follow what the program is doing.

Its the same sort of argument with loops both conditional and unconditional. Same with recursive functions: in all these examples you are able to relate easily the flow control of the program with the state space that is being read or written.

With the goto statement, it's hard to readily identify the type of context mentioned above, not only with respect to flow control in its own right (ifs, loops, select, case, function calls etc), but also its relation to the state space of the program.

rcgldr

Quote by chiro

A goto statement is non intuitive for most programmers.

I think the average person understands the concept of "goto", go to the store, go to Lombard Street, ... . The average programmer isn't going to have problems realizing that "goto xyz" transfers code to the line labeled "xyz:".

A goto is just a form of flow-control that does not have context information.

Rarely is goto used in a non-context mode. It's normally used as part of a conditional sequence such as if(...){ ...; ...; goto xyz;} That previous thread pretty much explained the situations where using goto would be good or bad:

http://www.physicsforums.com/showthread.php?t=308782

chiro

Quote by rcgldr

I think the average person understands the concept of "goto", go to the store, go to Lombard Street, ... . The average programmer isn't going to have problems realizing that "goto xyz" transfers code to the line labeled "xyz:".

Rarely is goto used in a non-context mode. It's normally used as part of a conditional sequence such as if(...){ ...; ...; goto xyz;} That previous thread pretty much explained the situations where using goto would be good or bad:

http://www.physicsforums.com/showthread.php?t=308782

Of course goto is easy to understand, but if you're a programmer with some experience, you are expecting clean structured code, and this kind of thing is disrupted with a goto statement. It's more of a forest from the trees approach: experienced programmers can look at well written code and decipher what the code is all about when the code is written well, but it can be very difficult to get this kind of grasp when the code is poorly written, and that includes unnecessary use of things like goto. Again I emphasize not just understanding what a single line of code does, but more along the lines of interpreting the whole subroutine at a higher level.

swartzism

The DO/CONTINUE format that I gave an example of is still used in 90,95,2003 and is even faster than DO/ENDDO. I wrote a small explanation why in the thread http://www.physicsforums.com/showthread.php?t=504768

Similar Threads for: Goto statement, mostly regarding Fortran
Thread	Forum	Replies
Fortran 90, goto	Programming & Comp Sci	13
FORTRAN 77 read statement	Engineering, Comp Sci, & Technology Homework	4
FORTRAN Write Statement Issue	Programming & Comp Sci	2
meaning for fortran statement	Programming & Comp Sci	1
Fortran 90 very basic question : else if statement	Programming & Comp Sci	6

I like Serena Recognitions: Homework Help	Goto statement, mostly regarding Fortran We like to call it "spaghetti". You can compare it to a rope that has become entangled. As you may know it takes a lot of skill and effort to discern how it is entangled. And it is a lot of work to untangle it.

rcgldr Recognitions: Homework Help	A previous and long thread about goto's. In some situations, for some programmers, they're better than the alternative: http://www.physicsforums.com/showthread.php?t=308782

gb7nash Recognitions: Homework Help	It's hard to follow and can get pretty insane if you have multiple goto's all over the place. Anyone trying to debug tons of goto's will probably throw their computer out the window.

swartzism	The DO/CONTINUE format that I gave an example of is still used in 90,95,2003 and is even faster than DO/ENDDO. I wrote a small explanation why in the thread http://www.physicsforums.com/showthread.php?t=504768