goto

I did not realize this was the Non Visual c++ forum, so my last post was way off. Coding your own routines in c++ in the style of the termination handler though (all cleanup routines in one exit location) is good style, though, because it allows for easy analysis of completeness. I stand by my "use if needed" statement though, with fists up and ready.

First I have to say I'm a C programmer, ok :cool:

Graham's talk about RAII doesn't seems to solve all problems... If you define a pointer object and later create an instance of it with the new-operator. How does RAII apply to that and what's the difference between RAII and a good old goto? Goto:s unwind the stack and I guess destructors are called then, or?

It seems that many of you think that it's absolutely wrong to use goto:s.. Black or white, black or white... when the color is gray :p

...Just my view.

First I rarely find a need for the "goto" statement. I try to not to use it. Also I rarely find the need of having multiple exit points of function calls. And I try to not to have multiple exit point.

But I only follow those rules as rules of thumbs, NOT rules of principle. It is possible, as a principle, that you can absolutely stay away from both goto and multiple exit point, and use alternative ways of achieving what you want. But some times the price of alternative is just too high to be worth it.

If in a specific situation, a goto statement or multiple exit point seems to be an attractive solution, I would NOT hesitate to use them. I do NOT understand arguments of people who tries to tell people "goto" is the mother of all evils.

First. Usage of goto NEVER implies a design flaw. It never implies any thing good or bad of the design. Usage of "goto" is purely an implementation issue. There is NOT a conceiveable design which would mandate usage of goto, and which can not be implemented without goto. I can't think of any thing like that.

Usage of goto has its pros and cons. Whether to use it or not is purely an implementation decision, based on individual's opinion of the balance of pros and cons. Some claim using goto is a bad design. It is never a design issue. Some claim using goto is error prone. Well programmers make all sorts of mistakes. I don't buy it that using goto automatically means your chance of making an error is significantly higher versus when you don't use it.

Show me some statistical data to back it up if you claim goto is more error prone.

Bottom line is: it is possible to stay away from goto completely and absolutely. But it is not necessary to do so. There are both good or bad use of goto. And when it seems to be a good place to use goto, there is no reason why you shouldn't use it.

Quote:

---

... and my point is that you'll waste an awful lot of time looking for a better or more valid example. There aren't any. The set of situations in which the use of goto is elegant, readable, maintainable and correct is vanishingly small.

---

Graham:
You have to realize that program code that satisfy elegant, readable, maintainable and correct all 4 conditions simply does not exist. So that's not a problem for just goto statement. Most times you have to settle for 3 out of the 4 you meantioned.

Take this computation task as an example: There are 8 short integers a0, a1, ...a7 and 8 other short integers b0, b1,...b7. I want to multiply each a with b (a0 with b0, a1 with b1, etc), divide the result of multiplication by 32768, and sum them up. And I need to make sure the result stays within the range. What's an elegant solution?

Using C/C++ you probably need to write any where from 10 to 20 lines of code and have to do a bunch of "if" to accomplish it. But using some SIMD assembly instruction I can do the whole thing in just one instruction. So who is the elegant?

Here is an example in which the use of goto is not perfect but is surely more elegant than other solutions. You need to do a switch statement in which depending on the switch value, you have to carry out a combination of tasks a0, a1,...an, and one of either b0 or b1 or b2. And the switch has about 100 differeent cases and you want to do it fast, so you really don't want to do it in two different switch statements. What do you do?

I would do this:

Code:

---

switch (val)
{
case 1:
    DoTaskA1();
    goto TaskB0;
    break;
case 2:
    DoTaskA2();
    goto TaskB0;
    break;
case 3:
    DoTaskA3();
    goto TaskB1;
    break;

case 4:
    DoTaskA4();
    goto TaskB0;
    break;

case 99:
    DoTaskA99();
Task_B1:
    DoTaskB1();
    break;

case 100:
    DoTaskA100();
Task_B0:
    DoTaskB0();
    break;

default:
    break;
}

---

Quote:

---

Originally posted by AnthonyMai
Paul said:


That's a reasonable imagination of what could happen. But unfortunately it is NOT TRUE. Don't spread the rumor. Check the fact first, Paul!

---

I think we must have posted at the same time. Right before you
posted this, I made another post modifying the post where I
made the "mistake". What I was talking about in that statement
were non-local gotos [and not the goto keyword]. I should have
made that clear [and I thought I did], but oh well: time to take
my lumps :)

--Paul

Quote:

---

Originally posted by j0nas
First I have to say I'm a C programmer, ok :cool:

Graham's talk about RAII doesn't seems to solve all problems... If you define a pointer object and later create an instance of it with the new-operator. How does RAII apply to that and what's the difference between RAII and a good old goto? Goto:s unwind the stack and I guess destructors are called then, or?

It seems that many of you think that it's absolutely wrong to use goto:s.. Black or white, black or white... when the color is gray :p

...Just my view.

---

A good practice to follow when programming in C++ is to not use
so-called naked pointers like you describe. If you have a pointer
and goto [the keyword] an area where the delete is never
called, you will have a resource leak. If you instead have a class
whose constructor does the new and destructor does the
delete, you won't ever have a resource leak because the
destructor will do the delete when the variable goes out of scope
... whether an exception is thrown or a goto takes you past the
delete or whatever [not the non-local gotos though].

That's the difference.

--Paul

Quote:

---

Originally posted by AnthonyMai
First I rarely find a need for the "goto" statement. I try to not to use it. Also I rarely find the need of having multiple exit points of function calls. And I try to not to have multiple exit point.

But I only follow those rules as rules of thumbs, NOT rules of principle. It is possible, as a principle, that you can absolutely stay away from both goto and multiple exit point, and use alternative ways of achieving what you want. But some times the price of alternative is just too high to be worth it.

If in a specific situation, a goto statement or multiple exit point seems to be an attractive solution, I would NOT hesitate to use them. I do NOT understand arguments of people who tries to tell people "goto" is the mother of all evils.

First. Usage of goto NEVER implies a design flaw. It never implies any thing good or bad of the design. Usage of "goto" is purely an implementation issue. There is NOT a conceiveable design which would mandate usage of goto, and which can not be implemented without goto. I can't think of any thing like that.

Usage of goto has its pros and cons. Whether to use it or not is purely an implementation decision, based on individual's opinion of the balance of pros and cons. Some claim using goto is a bad design. It is never a design issue. Some claim using goto is error prone. Well programmers make all sorts of mistakes. I don't buy it that using goto automatically means your chance of making an error is significantly higher versus when you don't use it.

Show me some statistical data to back it up if you claim goto is more error prone.

Bottom line is: it is possible to stay away from goto completely and absolutely. But it is not necessary to do so. There are both good or bad use of goto. And when it seems to be a good place to use goto, there is no reason why you shouldn't use it.

---

I wholeheartedly agree. This is one of those things that's open
to a wide amount of interpretation by everyone. Each person has
his own ideas regarding what is acceptable use of the goto
keyword. That's another reason why there was a mass exodus
away from the goto keyword in general: when used badly, the
goto keyword CAN create havoc.

--Paul

Doesn't your argments in favor the GOTO apply to almost every other contriversial C/C++ statement? For example, some people say never use FILE but use streams instead. Or how about the people who swear by templates in place of macros? Or global/static non-class variables. There are a whole host of these. Use, or non-use, of any of these is not a design flaw but largly the preferences of the coder. I feel more comfortable using FILE instead of streams and my programs reflect that.

And yes, there are some rare occasions to use goto -- I've even seen it once or twice in MFC code.

It's not merely a preference. It's a maintenance issue. That's primarily why goto's are considered bad. Because it can be difficult to maintain. If you set a breakpoint after a goto flag, it's harder to determine how you got there. It's one thing to imagine a method with a single goto that goes forward. Now imagine a method with three gotos that go forward and back. This becomes very difficult to deal with.

Preferring FILE to streams is a real maintenance issue. Maybe you are certain that your code does not need to be portable or that you'll always have a good portability tool. However good and true this is, it is still an assumption.

Wether it's a good decision or not to use FILE over streams is not really important to this discussion. My point is that there is more to it than "preference." There is a potential cost to it.

Jeff

I've seen badly nested if's, do/while, and horrendous looking branched recursive function calls. Does this mean that these language features are bad or that they have been used badly?

Quote:

---

Originally posted by galathaea
I've seen badly nested if's, do/while, and horrendous looking branched recursive function calls. Does this mean that these language features are bad or that they have been used badly?

---

In my opinion, it'd mean that the feature was used badly. The
problem with the goto keyword is that it's a lot more flexible
than other commands. Everyone seems to have their own
interpretation on what is "proper" when it comes to the goto
keyword. Because of that, it's hard to quantify whether or not
a particular usage is a poor decision.

doesn't everyone have their own interpretation on what is proper if/do/while nesting or proper branched recursion style? I've seen several different styles of each. Shouldn't we just say, is this readable and maintainable. Period. Without the taboos.

I really miss the setjmp() and longjmp() -- they're like goto but can jump to anywhere within the program, while goto is limited to the function in which it is used. If you have a hard time following a goto, you ought to try figuring out where a longjmp() is going to go!! If there is only one setjmp, then its pretty easy.

Quote:

---

It's not merely a preference. It's a maintenance issue. That's primarily why goto's are considered bad. Because it can be difficult to maintain.

---

Maintenance issue exists for all language features and I don't see how goto is special. It's all up to how you use it. You can do a wild goto and jump to some place never expected and it's going to be headache. You can throw in 10 different "return" here and there and some resorces never gets cleaned, and it's going to be a headache. If that happens, blame on the person who inproperly used the language feature, not the language feature itself.

goto can be used in a pretty elegant, well structures, and quite maintainable way. It's up to how you use it.

Quote:

---

If you set a breakpoint after a goto flag, it's harder to determine how you got there.

---

Would you be able to figure out how you get there if you set a break point right after a long loop which contains quite a number of different places where "break" is called upon various conditions? You can't either.

As a matter of fact, if you simply replace all the "break" with a "goto" that go to the line right after the loop, chances are the compiled code will look exactly the same and contain the same assembly code.

Quote:

---

It's one thing to imagine a method with a single goto that goes forward. Now imagine a method with three gotos that go forward and back. This becomes very difficult to deal with.

---

If one has a legitimate reason to go backwards. What's wrong with goto backwards? If one does not have a good reason to go backwards, why would one goto backwards just for the sack of goto backwards?

One legitimate use of goto backwards goes like this:

Quote:

---

start_calc:
for (i=0; i<1000; i++)
{
for (j=0; j<1000; j++)
{
for (k=0; k<1000; k++)
{
Manipulate Data[i][j][k];

// If some condition raises and we have to re-start
// the calculation again.
if (Something_Goes_Wrong)
{
goto start_calc;
}

// If we have found what we want and there is no need to continue.
if (We_are_all_done_already)
{
goto end_calc;
}
}
}
}
end_calc:

---

A side note. One language feature that I find totally unacceptable, and causes maintenance problem, is the C++ exceptions.

Exceptions are bad because higher level code never knows who will throw exceptions and from where and under what condition. And the one who throw exceptions never knows who will catch them and where it will be catched and under what circumstance it will be catched. Such uncertainly is the worst enemy in programming.

We see so many uncatched exceptions in day to day code, and even more exceptions caught at wrong places! "Unhandled exceptions" can be accounted for a great portion of all crashing software bugs.

Even worse, C++ exceptions are some sort of contageous decease. A function that does not throw any exceptions at all itself, could be a function that actually throws exception, if amoung the functions it calls, some do throw exception, or if the functions it calls do not catch exceptions from lower level code.
So it is contagenous. And you become an exception throwing function without you even realize it.


Worse of all, no one bothers to catch exceptions. It would be ideal if wheneve you call some exception throwing function (which is basically every thing), you need to wrape the call in a try/catch block. For example when you call new. But no one does it.

Some claim he can "strategically place a few try/catch here and there", and it will catch all exceptions. First that is impossible to do. Second, it is impossible to maintain, since if the code changes, your strategically placed try/catch may need to strategically re-positioned. It is as tough as trying to catch the DC sniper or trying to catch Ben Laden. You simply can not do it with a few dozen or so soldiers "strategically" placed here and there.

Exceptions are evil.

Quote:

---

switch (val)
{
case 1:
DoTaskA1();
goto TaskB0;
break;
case 2:
DoTaskA2();
goto TaskB0;
break;
case 3:
DoTaskA3();
goto TaskB1;
break;

case 4:
DoTaskA4();
goto TaskB0;
break;

case 99:
DoTaskA99();
Task_B1:
DoTaskB1();
break;

case 100:
DoTaskA100();
Task_B0:
DoTaskB0();
break;

default:
break;
}

---

No offence, but the above code is a poor execuse for justifying a goto statement.

You can easily accomplish the samething by adding another switch statement, and the code would look more readable, and be easier to follow.

Example

Code:

---


int main(int argc, char* argv[])
{
        int SecondTask = 0;
        enum {Task_B0 = 1, Task_B1 = 2};
        switch (argc)
        {
        case 1:
                DoTaskA1();
                SecondTask = Task_B0;
                break;
        case 2:
                DoTaskA2();
                SecondTask = Task_B0;
                break;
        case 3:
                DoTaskA3();
                SecondTask = Task_B1;
                break;
        case 4:
                DoTaskA4();
                SecondTask = Task_B0;
                break;
        case 99:
                DoTaskA99();
                SecondTask = Task_B1;
                DoTaskB1();
                break;
               
        case 100:
                DoTaskA100();
                SecondTask = Task_B0;
                break;
               
        default:
                break;
        }

        switch(SecondTask)
        {
        case Task_B1:
                DoTaskB1();
                break;
        case Task_B0:
                DoTaskB0();
                break;
        }
       
        return 0;
}

---

I can find absolutely no excuse for needing a goto statement.
I've been programming in C/C++ since 1987.
In my first year of programming, when I didn't know any better, I did use goto's. The fact that my first language was BASIC, may it that much more tempting to use goto’s.

Since my second year of programming in C/C++ (1988) I have not found a single situation in which I had to use a goto statement.

I have not run into any condition in which I thought, “Wow! …. A goto statement would work so much better here!”

The use of goto’s too often results in spaghetti code, that is hard to read, and hard to maintain.
My advice is NEVER, NEVER, NEVER use a goto statement….. There always a better non-goto method to accomplish the same thing or better.

It’s not required for C/C++ programming, and your code will be easier to follow and easier to maintain without it.