'goto' is perfectly valid
There is nothing inherently 'evil' or 'wrong' about using goto. Like any other tool in one's programming toolbox, it has a specific place and use it is best suited for.
There is no intelligent basis whatsoever behind this unwarranted discrimination against 'goto'. The Pascal Purist who came up with a dislike for goto didn't know assembly, and only made such a discrimination because seeing 'goto' in code wasn't 'pretty'.
Well, I got news-- high-performance code usually isn't pretty. The faster something is, the simpler and more straightforward it is. It's a simple law of physics.
And 'goto' doesn't require a test-- it's the equivalent of a jump instruction in assembly.
Re: 'goto' is perfectly valid
Quote:
Originally posted by Sayeh
There is nothing inherently 'evil' or 'wrong' about using goto. Like any other tool in one's programming toolbox, it has a specific place and use it is best suited for.
This is very true
Quote:
There is no intelligent basis whatsoever behind this unwarranted discrimination against 'goto'. The Pascal Purist who came up with a dislike for goto didn't know assembly, and only made such a discrimination because seeing 'goto' in code wasn't 'pretty'.
This I will disagree with. I started with languages that had no structure and block concepts, these had to be shoehorned into the language. The discrimination against 'goto' has to do not with the 'prettiness' of the code but the processing flow -- the 'spaghettiness' of the code. It's very difficult to follow code with a multitude of goto's whereas blocks are much easier on the understanding. Now don't get me wrong, for small programs the goto does not necessarily create poor code, it's the programmer. But for complex code with a lot of branching (algorithms that are difficult to understand and implement) the goto generally will make the code more difficult to follow.
Quote:
Well, I got news-- high-performance code usually isn't pretty. The faster something is, the simpler and more straightforward it is. It's a simple law of physics.
This is old news. But you are using terms here that can be extremely contradictary. Generally, if you program for speed, the code will not be easy to understand and maintain, whereas if you code for maintainability and simplicity, the more higher-level concepts you will need to use, slowing down the processing. Why else do many compilers have two modes -- compile for speed (larger size) or size (slower processing)?
Quote:
And 'goto' doesn't require a test-- it's the equivalent of a jump instruction in assembly.
Duh! But neither does a defined block. But in general, the reason for a goto is that previously a test has been done and we are at the conclusion of the test. The goto simply jumps around code that is written for a different test condition. Identical to a switch.