Thread: Problem with goto

that is a function that just happens to have a name that starts with "goto"... Not a goto statement. There's a world of difference.

Goto has its uses. And yes, it has a place on structured programming, object oriented programming, procedural programming and all the x programmings out there.

Originally Posted by cdkiller

Mario. I guess in a way i see your point. in my first programming course i was a big fan of goto in my projects but the teacher did not like us using goto. i always thought there must have some reason why the creators of C++ put a goto function so why can't i get credit for using it. up to now i am not exactly clear as to why most books and other resources direct people away from goto, but i think what they really mean to say is to not use goto for control structures. but like swgh said, goto has other uses.

anyway hopefully somebody could tell us why we are schooled to shy away from goto and #define. speaking of that, i hate loud cars that just pass by and make so much noise for no good reason. hopefully someday soon i will complete my directed emp shockwave generator so i could teach those punks a lesson without blacking out the entire neighbourhood

With goto, it makes compiler optimizations very difficult; in fact often it will require a global disabling of compiler optimizing to make it actually work correctly. In general it makes the compiler's job a lot harder and there are often bugs in how goto is implemented which can leak memory or crash the program. In fact because many compilers will actually silently disable optimizations for code which contains goto statements, it's often far less efficient.

As to #define, it does not respect any scope rules; it's essentially a "find and replace" that happens in preprocessing. There are other methods to solve these problems that do obey scope rules.

In general:

If the define is for a constant, use const int instead.
If it's for aliasing a typename, use typedef instead.

Originally Posted by twomers

Wow, fastest thread ever! About one post per minute!!

Not really...Anyone remember this thread?

Back on topic though:

Originally Posted by cdkiller

i always thought there must have some reason why the creators of C++ put a goto function so why can't i get credit for using it

Maybe it was included because C had goto? Sometimes it might be more elegant to use goto in a case such as this (arguably, of course):

Code:

void Foo(void)
{
//...

  if(!Bar1())
    goto Cleanup;
  if (!Bar2())
    goto Cleanup;

Cleanup:
  //deallocation, etc.
}

However, in C++, I don't know if I've ever seen a case where goto was a good solution (consider in this case that if RAII is used, object destructors can perform cleanup)

As I said before on this thread there's at least three justifications for goto.

1. Exiting deeply nested loops.
2. Perfomance critical situations.
3. Parsers and code generators.

Originally Posted by Mario F.

2. Perfomance critical situations.

I disagree here. Many compilers have a very hard time with goto because it often seriously impairs their ability to optimize code. Often the compiler will choose not to optimize the code at all in the presence of goto statements.

It all has to be evaluated Cat.

Not all situations impair the compiler from performing its optimizations. And certainly on those that do, some can also be dealt with by changing the way we code (and not necessarily removing the goto statement) and yet others by tweaking with the compiler options.

And then we have those situations that simply cannot be dealt with in the presence of a goto statement. For those, I give credit to your words.

Compilers are not that dumb in the face of a goto. It all depends on how it is used. Certainly a performance conscious developer, coding a high-performance algorithm will have the necessary knowledge to evaluate if a goto will improve his code or not. More often than not, it will indeed.

I don't know where you get this idea that goto statements seriously impair optimizations. I'm sure there are cases where they do. But I'm sure there are cases... where they don't.