Is using goto a bad practice

[SuperKoko]

Using exceptions for that is evil.
Not only is it perversing the system, but it's also likely to have incredibely bad performances. Ssomething like more than 200 microseconds for each throw statement... More for "zero overhead" exceptions.

In C++ exceptions must never be thrown in the normal control flow of a program.
There are enterprises who use tools to log every exception in a file and never release the application before zero exceptions are thrown in the normal control flow of the program.

Gotos are evil. Ok. But perversions used to avoid gotos can be worst.

[exterminator]

In Javascript (ECMA Script 3. ed) you got break and continue statements just as in C/C++, but in addition you can add an optional label to the keyword:

continue [label];

and

break [label];

outerloop:
while (a)
{
    while (b)
    {
        if (someCondition)
            break outerLoop;
    }
}

This seems like an attempt to avoid the use of goto and other messy code to break/continue nested loops. What do you anti-goto'ers out there think of such a construct?

break can be implemented in terms of goto. And that is the kind of limitation that break suffers over goto and hence I feel the goto debate keeps popping up. This would be a nice feature and I have read discussions around something like that happening on clc++m.

[Graham]

I programmed in Fortran for 20 years, so I have a deep-rooted loathing for goto in all its forms, including break and continue. Gotos increase the time taken to understand and to maintain any piece of code. If I never see another one, it will be too soon.

[treuss]

Who ressurrected this one and a half year old thread? I'm sure we will see the goto statement being removed from the C++ standard sooner, than we will see this discussion reach a conclusion.

[KevinHall]

Hi Kevin,

The problem that you mentioned above can be very easily circumvented by defining a
unique identifier (e.g. a class), and then throwing that.
[/code]

Wow, a unique class for every goto? That sounds much more maintainable than just using a goto! Then there's the argument about performance (which others have brought up).

But you obviously missed the point I made earlier. If you are going to use goto-like capabilities, then use a goto! Don't simulate a goto with features that aren't designed to be gotos. You'll only confuse other people who have to maintain the application.

- Kevin

[artella]

Hi Kevin,

Your point about having multiple classes is a very good one (in addition to "confusion factor" you mentioned and also time issue pointed out by SuperKoko). In the case of your gotos appearing in sequentially separated code, I think you should be able to recycle the same class. However in nested gotos, you could have some serious problems. For example if you have two gotos, and the inner goto refers to a point in the code appearing after the reference of the outer goto, then you couldn’t reuse the same class. So this “alternative” becomes, like you said, messier and messier.

Thanks.

Hi Treus,

I’m afraid I resurrected it. I thought that taking refuge in an old query would be the best way for me to ask a question on such an overdiscussed topic. It wont happen again

[KevinHall]

Hi Treus,

I’m afraid I resurrected it. I thought that taking refuge in an old query would be the best way for me to ask a question on such an overdiscussed topic. It wont happen again

Personally, I'd rather resurrect an old thread rather than starting a whole new one. At least all the history is in the same place then. But that is just my humble opinion....

(Of course it would be best to see if the answer already existed in the thread before resurrecting it.)

- Kevin

[JVene]

Gotos are fundamental to computers really so theres no avoiding them completely. I mean its translated to assembly with labels and jumps anyways.

I think 'goto' was included in the spirit of C's position as an assembler (in it's original inception) - the unconditional jump was probably a significant portion of the assembler the original designers of C were intending to support.

In the last 20 years of my own work, I've not had one reason to use goto (with a caveat I visit below), covering diverse topics that range from business applications to 3D simulations. Branchpoints, conditional and otherwise, are implied by other graceful constructs, like the close brackets and the return from a function.

I think the notion of goto should be considered more in the light of what you're attempting to 'instruct' the computer to do. The more information you can include in your expression, the better the optimizer is able to do it's work. An unconditional branch doesn't carry with it much information, and may actually obviate the compiler's ability to restructure your code depending on context.

The only exception where I have used goto is when I've mixed assembler and C++/C - in which case one could argue that I was using a C construct in place of an assembler counterpoint, and therefore not actually writing in C/C++.