Re: Is using goto a bad practice
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 :)
Re: Is using goto a bad practice
Quote:
Originally Posted by artella
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
Re: Is using goto a bad practice
Quote:
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++.
