Aliii: Some things exist as an evil legacy from the dark times.
I know that. But theres no "dark times" here ....many people are just allergic to goto I think:)
C++ - Is Goto a Good Practice?
I know that. But theres no "dark times" here ....many people are just allergic to goto I think:)
[quote name='rnlf' timestamp='1352909335' post='5000944']
Aliii: Some things exist as an evil legacy from the dark times.
I know that. But theres no "dark times" here ....many people are just allergic to goto I think:)
[/quote]
People don't just avoid code mechanisms without a reason, in my experience there's always a better and cleaner way to solve a problem than by using goto.
And there are definitely "dark ages", C and C++ have been around for quite a while now, and both languages have evolved a lot, so it's only natural that there are features in both which have somewhat of a legacy.
I think you've probably got your answer by now, but just to give my two cents - the use of GOTO in C++ can completely undermine the object oriented design of the language, which is after all the whole point.
[quote name='Aliii' timestamp='1352923452' post='5000998']
[quote name='rnlf' timestamp='1352909335' post='5000944']
Aliii: Some things exist as an evil legacy from the dark times.
I know that. But theres no "dark times" here ....many people are just allergic to goto I think:)
[/quote]
People don't just avoid code mechanisms without a reason, in my experience there's always a better and cleaner way to solve a problem than by using goto.
And there are definitely "dark ages", C and C++ have been around for quite a while now, and both languages have evolved a lot, so it's only natural that there are features in both which have somewhat of a legacy.
[/quote]
It always worked fine for me. I wonder how many of those people who blame it actually used it and had all those horrible things happen to them ...and to their code. (Maybe no one:)
Of course dont use it when working in a team, dont use it in functions that are more than lets say 60 lines, ....and dont combine it with lots of break, continue, recursion and function pointers.
*snip*
It's already a warning sign if you have to make a list of some quite common and maybe essential language features you shouldn't use together with goto, just saying.
Here's another one for the list:
Using goto statements can make it really damn hard to prove the correctness of your program since it completely allows you to break your program's structure. Not being able to prove that your program works as it's supposed to will send you straight to debugging hell, and that's one place you really don't want to be.
Maybe using lots of goto statements works for you, but I can think of hundreds of designs which would also work but which would be horrible to maintain, extend and debug. We don't advise against using goto because we have some sort of weird prejudice against it, we advise against it because when it comes to C++ in almost all the cases there's a better and cleaner tool for the job.
And no I'm going to stop, I'm starting to ramble...
"It's already a warning sign if you have to make a list of some quite common and maybe essential language features you shouldn't use together with goto, just saying."
....it was not a Dont-use-this-with-goto-Bible and I didnt have to make it:) ....I just gave some examples.(I think they are quite accurate though.) Plus I used the words "lots of" but nevermind
"Maybe using lots of goto statements works for you"
It doesnt, because I dont use lots of goto.
I dont wanna argue, Ive just told my experiences with goto. You almost seem like atacking me for it.
....it was not a Dont-use-this-with-goto-Bible and I didnt have to make it:) ....I just gave some examples.(I think they are quite accurate though.) Plus I used the words "lots of" but nevermind
"Maybe using lots of goto statements works for you"
It doesnt, because I dont use lots of goto.
I dont wanna argue, Ive just told my experiences with goto. You almost seem like atacking me for it.
It seems like people are mostly agreeing that goto should be avoided whenever possible and the program structure questioned otherwise.
Hopefully we don't need another 'little scene'. (Though I have to admit they can be pretty amusing.)
Hopefully we don't need another 'little scene'. (Though I have to admit they can be pretty amusing.)
As long as a language has [font=courier new,courier,monospace]goto[/font], it isn't intrinsically bad to use it.
It is possible to use it either in a right or in a wrong way.
The thing is that as a language has a higher level than others, it is in general spontaneously easier and natural to avoid using [font=courier new,courier,monospace]goto[/font].
__________________________________________________
__________________________________________________
__________________________________________________
I am currently mainly an x86 Assembly language programmer but I can program a bit of C, Pascal, and a good amount of JavaScript and PHP, so I can tell you that in languages higher than Assembly (including C) I rarely use [font=courier new,courier,monospace]goto[/font]. It might seem paradoxical but Assembly language has helped me no end to find ways to program very elegantly and concisely without using [font=courier new,courier,monospace]goto[/font], or excessive nested [font=courier new,courier,monospace]if[/font]s or nested function calls.
Now, I find myself all the time converting higher-level code to Assembly by hand. In that case, you can see that down to the bare metal level all of your loops, conditional code and the like, must be converted to conditional Assembly instructions that work exactly like [font=courier new,courier,monospace]goto[/font], and in general it can't be avoided at that point (which by the way is by no means an obsolete environment but just the very essence of a machine).
I also find myself converting Assembly code to higher-level code, and in this case I must find ways to do it efficiently. I almost never need to use [font=courier new,courier,monospace]goto[/font] when doing this.
In other words, knowing how to use [font=courier new,courier,monospace]goto[/font] properly is necessary, not to be abused and not to be ignored either (specially if you know and want to use Assembly language, among other things, to work a little bit in designing or understanding compiler-like programs that generate Assembly code).
If you use it too much in a high-level language, chances are that you are still in a very incipient level of knowledge for a proper implementation of your logic when you could use syntax elements better suited for what you want to achieve in that language (e.g., using [font=courier new,courier,monospace]goto[/font] for no special reason when you could have used a [font=courier new,courier,monospace]while[/font] loop that maybe you just didn't know how to use).
It is possible to use it either in a right or in a wrong way.
The thing is that as a language has a higher level than others, it is in general spontaneously easier and natural to avoid using [font=courier new,courier,monospace]goto[/font].
__________________________________________________
__________________________________________________
__________________________________________________
I am currently mainly an x86 Assembly language programmer but I can program a bit of C, Pascal, and a good amount of JavaScript and PHP, so I can tell you that in languages higher than Assembly (including C) I rarely use [font=courier new,courier,monospace]goto[/font]. It might seem paradoxical but Assembly language has helped me no end to find ways to program very elegantly and concisely without using [font=courier new,courier,monospace]goto[/font], or excessive nested [font=courier new,courier,monospace]if[/font]s or nested function calls.
Now, I find myself all the time converting higher-level code to Assembly by hand. In that case, you can see that down to the bare metal level all of your loops, conditional code and the like, must be converted to conditional Assembly instructions that work exactly like [font=courier new,courier,monospace]goto[/font], and in general it can't be avoided at that point (which by the way is by no means an obsolete environment but just the very essence of a machine).
I also find myself converting Assembly code to higher-level code, and in this case I must find ways to do it efficiently. I almost never need to use [font=courier new,courier,monospace]goto[/font] when doing this.
In other words, knowing how to use [font=courier new,courier,monospace]goto[/font] properly is necessary, not to be abused and not to be ignored either (specially if you know and want to use Assembly language, among other things, to work a little bit in designing or understanding compiler-like programs that generate Assembly code).
If you use it too much in a high-level language, chances are that you are still in a very incipient level of knowledge for a proper implementation of your logic when you could use syntax elements better suited for what you want to achieve in that language (e.g., using [font=courier new,courier,monospace]goto[/font] for no special reason when you could have used a [font=courier new,courier,monospace]while[/font] loop that maybe you just didn't know how to use).
It might seem paradoxical but Assembly language has helped me no end to find ways to program very elegantly and concisely without using [font=courier new,courier,monospace]goto[/font], or excessive nested [font=courier new,courier,monospace]if[/font]s or nested function calls.
I've also noticed this in my own coding. I think part of it is the inversion of the logic with conditional jumps. Somehow just doing a little bit of work with that subconsciously reorganized my brain and now my loops and conditionals come out smoother. It's strange that the inversion is unintuitive but somehow results in a better 'natural flow' once it's understood.
Only skimmed through the topic,
In a game menu scenario I would go with a finite state machine of game states and loop through it accordingly.
In a game menu scenario I would go with a finite state machine of game states and loop through it accordingly.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
