Why is goto the devil and exiting programs question.

**Elysia** · 08-05-2009

I fail to see how for loops are easier to read, though, because essentially, they are the same thing.

Code:

for (int i = 0; i < 10; i++);

Same as:

Code:

int i = 0;
while (i < 10)
    i++;

Not much difference, is there?

As for goto: try writing a flow chart. Then add conditions and gotos and you'll see arrows all over the place in the end. That's why it's called a mess. This is why we use loops.

**laserlight** · 08-05-2009

Originally Posted by Elysia

Not much difference, is there?

With the for loop, I can mentally register the kind of iteration to expect (of course, the same can be said of the while loop, but as a different kind of iteration). Furthermore, in your example, the scope of i is restricted to the for loop, but extends beyond the while loop.

**Elysia** · 08-05-2009

Yes, well I mostly targeting the loop condition which is usually the part of the loop that has the most problems grasping. And both for and while use the same type of condition. Loop while this condition is true.
It makes me wonder why they didn't add a loop that loops UNTIL the condition is true, such as Visual Basic has. For many, it is easier to grasp than inverted logic.

**laserlight** · 08-05-2009

Originally Posted by Elysia

Yes, well I mostly targeting the loop condition which is usually the part of the loop that has the most problems grasping. And both for and while use the same type of condition. Loop while this condition is true.

However, you would then be comparing where they are the same, not where they are different. If you want to choose between them, where they differ would be important.

**Mario F.** · 08-05-2009

Originally Posted by Elysia

Yes, well I mostly targeting the loop condition which is usually the part of the loop that has the most problems grasping. And both for and while use the same type of condition. Loop while this condition is true.
It makes me wonder why they didn't add a loop that loops UNTIL the condition is true, such as Visual Basic has. For many, it is easier to grasp than inverted logic.

Not following you here Elysia.
C++ loops are essentially loop until false. But loop until true is what seems inverted logic since you are validating the next iteration on a negative predicate(?).

Anyways, In any case you can implement loop until true, by removing the condition and using exit statements (break, return, throw, and... goto(!))

**sean** · 08-05-2009

I would say it's mainly because C was designed to provide very a bare minimum set of abstractions, and is often just syntactic sugar for common operations in Assembly. It wasn't designed to be easy to understand for noobs. Visual Basic to larger extent was.

**cpjust** · 08-05-2009

In over a decade, there was only one time when I was tempted to use goto to get out of a deeply nested bunch of loops & if statements... Unfortunately Java wouldn't let me use goto in the place I wanted, so I had to make the code even uglier.
But in all other cases, there is a better way to do things other than using goto, and in all cases, it is never required to use goto. So until you become a lot more experienced, it's better to just stay away from it and pretend goto doesn't exist.

**Elysia** · 08-05-2009

Originally Posted by Mario F.

Not following you here Elysia.
C++ loops are essentially loop until false. But loop until true is what seems inverted logic since you are validating the next iteration on a negative predicate(?).

Anyways, In any case you can implement loop until true, by removing the condition and using exit statements (break, return, throw, and... goto(!))

I meant that in VB, there is Do...Loop While and Do...Loop Until. Two different ones, and when you think about it, we want things to loop UNTIL a condition is true. That is often how my mindset is. Dunno about others, but I'd rather think a lot of people think like that.
So then the while loop becomes inverted logic. Loop until this is FALSE essentially.
Thankfully, it is easy to fix by just inverting the logic, but it's interesting nevertheless.

**rossipoo** · 08-05-2009

Here is an illustration of how much using loops can improve the readability of code. I'll use loops and gotos to solve a simple problem, creating a multiplication table:

Using for loops:

Code:

	for (int a = 1; a <= 6; ++a) {
		for (int b = a; b <= a * 6; b += a) {
			std::cout << std::setw (3) << b << " ";
		}
		std::cout << "\n\n";
	}

Directly converting those for loops to gotos:

Code:

	int a = 1;
start_loop_a:;
	if ( !(a <= 6)) goto end_loop_a;
	int b = a;
start_loop_b:;
	if ( !(b <= a * 6)) goto end_loop_b;
	std::cout << std::setw (3) << b << " ";
	b += a;
	goto start_loop_b;
end_loop_b:;
	std::cout << "\n\n";
	++a;
	goto start_loop_a;
end_loop_a:;

It is possible to do it using only one loop by adjusting the logic slightly, though not much more elegantly:

Code:

	int a = 1;
	int b = a;
start_loop_c:;
	if ( !(a <= 6))
		goto end_loop_c;
	std::cout << std::setw (3) << b << " ";
	b += a;
	if ( !(b <= a * 6)) {
		++a;
		b = a;
		std::cout << "\n\n";
	}
	goto start_loop_c;
end_loop_c:;

**brewbuck** · 08-05-2009

Heark back to languages like some of the original BASIC implementations. These languages only supported IF-statements of the form:

Code:

IF expr THEN stmt

Where STMT is a single statement. In most situations this FORCES you to use goto in order to jump to a code block that implements anything more complex than a single statement. This usage was so common that often you could omit the keyword "goto" altogether and it would be implied:

Code:

This:
IF expr THEN 200

Means the same as:
IF expr THEN GOTO 200

As a result, programs were a horrible mess of gotos, scattered code blocks, and obscure control flow.

goto was kept around in the C language because, as you remember, the C language was created in order to implement the UNIX kernel, a piece of code with strict performance and size requirements. goto can be used in some clever (read: hard to understand) ways that slightly improve performance or decrease code size. These considerations are less and less relevant.

In addition, compilers perform control flow analysis during optimization, in order to infer the relationships betweens variables and data flows. Some of the more powerful optimization algorithms depend on control flow graphs that are structured in a certain way -- using structured concepts automatically guarantees that the flow graph is reducible. But once you start using goto, you may create a flow graph that the analyzer cannot understand, and the result is that the compiler applies zero optimization to the entire function, or at least to a subgraph.

In short, using goto can counterintuitively HURT performance by confusing the hell out of the compiler. Compilers used to be dumb, and you needed goto to help them out. Now they're smarter than you.

**Jefff** · 08-05-2009

So, to pack it into a metphore, using a goto statement at the wrong time is basically as appropriate as running naked across the stadium during a football game.

**iMalc** · 08-06-2009

Originally Posted by Jefff

So, to pack it into a metphore, using a goto statement at the wrong time is basically as appropriate as running naked across the stadium during a football game.

In that case, using it at the "right time" (assuming there is such a thing) is like running naked across the stadium when it's empty. If you're lucky nobody will notice or care.

**Jefff** · 08-09-2009

I found another issue where I would find goto useful, but what are the alternatives?
This function should restart itself when an invalid menu section is selected.

Code:

/*	 Main Menu	 */

#include "stdafx.h"
#include <iostream>
#include "menu.h"
using namespace std;



void menu()	{
	cout<<"#########################"<<endl;
	cout<<"FILE I/O TEST APPLICATION"<<endl;
	cout<<"#########################"<<endl<<endl;
	
	
	cout<<"<1>List entries"<<endl;
	cout<<"<2>Display specific entry"<<endl;
	cout<<"<3>Create new entry"<<endl;
	cout<<"<0>Exit program"<<endl;
	cout<<"Select function: ";



	//Get selected menu
	int m;
	cin>>m;


	switch (m)	{

		case 0:
			exitprogram();

			



	}
}


void exitprogram()	{
	cout<<"<0>Exiting...."<<endl;
}

Now I can think of several ways:

1. Use goto to hop back to the start of it.
2. Use some form of return value that tells the main function to start menu() again. However I seem to mess up something when trying to use return values. What is the correct syntax to assign a return value of a function to a variable?

**BEN10** · 08-09-2009

If an invalid entry is selected, you can simply call the function recursively. For that you can add a default case which calls the menu function.
>>What is the correct syntax to assign a return value of a function to a variable?

for eg f() returns a value.

Code:

int i;
i=f();

**Jefff** · 08-09-2009

Would calling a function itself create some weird and dangerous itself calling loop? The compiler warned when I tried.

Also this appears to run the function itself when assigning it to a variable:

Code:

int i;
i=f();

I modified the menu function to look like that:
It should return the variable m to the main program when it is within range, if not, it should return -1.

Code:

int menu()	{
	cout<<"#########################"<<endl;
	cout<<"FILE I/O TEST APPLICATION"<<endl;
	cout<<"#########################"<<endl<<endl;
	
	
	cout<<"<1>List entries"<<endl;
	cout<<"<2>Display specific entry"<<endl;
	cout<<"<3>Create new entry"<<endl;
	cout<<"<0>Exit program"<<endl;
	cout<<"Select function: ";



	//Get selected menu
	int m;
	cin>>m;

	//Check if valid selection
	if (m > 3 || m < 0)	{
	cout<<"<ERROR>Invalid selection, returning to main menu..."<<endl;
	return -1
	}
	else	{
		return m;
	}



}

Then I have to use a silly if/else in the main function to decide on how to proceed. And having a clunky if/else in my main function for that just feels wrong. I am trying to keep the main function totally clean (only use it to call function), so I would like to know how to tell a function to restart itself without using goto and without calling itself again and again.

Thread: Why is goto the devil and exiting programs question.

Thread Tools

Search Thread

Display