Goto is realy nothing you should think about.
Go programming and don't argue about nonsense.
Why Ignore GOTO
999999999:
Still, gotos are great for beginning programmers to learn, but write some code, very complex code using it, then go back to it 5 years later. You'll hate yourself for having used goto. (Been there, done that...in the good old BASIC days.)
int i,j;for (i=0;i<x;i++){ for (j=0;j<y;j++) { if ((j+i)*sqrt(q)<i*(j+r)) { i=x; break; } }}// No gotoStill, gotos are great for beginning programmers to learn, but write some code, very complex code using it, then go back to it 5 years later. You'll hate yourself for having used goto. (Been there, done that...in the good old BASIC days.)
Quote:Original post by 999999999Yes, but it modifies the outer loop counter to abort that one too.
but that breaks stops only the inside loop, right?
In conclusion, if you feel that such hacks are motivated solely to get rid of a GOTO statement then you'd better just split off the inner loop to a separate function instead (or place both last in a function and return instead of break).
Quote:Original post by Christer Ericson
Anyway, it's really this simple: fundamentalism of any kind -- whether GOTOs, religion, or something else entirely -- is never good. Additionally, never say never. ;)
No, it's not that simple. Things never are. [wink]
"Fundamentalism" in the case of GOTO's can be justified, because 1) there are no real reason to actually use them (you can always do the same stuff without them), and 2) they turn a lot of people off. Put it like this, if the topic of GOTO's can spawn a 5-page thread here in a few days, then it will likely cause a lot of debate between the your team's programmers as well. And you don't really need that, if you're trying to actually get work done.
I think the kind of fundamentalism that goes "Don't do stuff in your code that other programmers on your team will hate you for" is fully justified.
I agree, if you look at a GOTO statement isolated, then yes, it can be harmless, and true, saying it should "never" be used would be going too far. But when you look at it as a tool which does nothing you can't do otherwise, and also encourages sloppy coding, and which is a very controversial topic between programmers already... Then I'd say it's fair to *never* use it.
Quote:Original post by doynaxQuote:Original post by 999999999Yes, but it modifies the outer loop counter to abort that one too.
but that breaks stops only the inside loop, right?
In conclusion, if you feel that such hacks are motivated solely to get rid of a GOTO statement then you'd better just split off the inner loop to a separate function instead (or place both last in a function and return instead of break).
Not for this simple example. eg:
for (int i=0,j=0;i<x;i+=(j=(j<y) ? (j+1) : 0) ? 0 : 1) if ((j+i)*sqrt(q)<i*(j+r)) break;// No goto, but highly crypticAnd unless I mucked something up, that should work fine.
Quote:Original post by NycholdI'm quite not sure what you're trying to show.Quote:Original post by doynaxQuote:Original post by 999999999Yes, but it modifies the outer loop counter to abort that one too.
but that breaks stops only the inside loop, right?
In conclusion, if you feel that such hacks are motivated solely to get rid of a GOTO statement then you'd better just split off the inner loop to a separate function instead (or place both last in a function and return instead of break).
Not for this simple example. eg:for (int i=0,j=0;i<x;i+=(j=(j<y) ? (j+1) : 0) ? 0 : 1) if ((j+i)*sqrt(q)<i*(j+r)) break;// No goto, but highly cryptic
And unless I mucked something up, that should work fine.
I acknowledged that your original method worked. My point was that it's unnecessarily compicated compared to the alternatives (such splitting things up into separate functions or even GOTO).
I suppose you've just given me an even better example. At least I think we can all agree that GOTO is far better than that mess.. =)
Quote:Original post by Anonymous Poster
Yes, this may be *good enough* for very small programs, or large programs with a robust memory management architecture. I assume you don't include this technique while developing multi-threaded applications?
Hmm... honestly, I've never personally had to write multi-threaded code. It's probably my ignorance talking, but I don't see why this technique would be worse in multi-threaded applications. But let's not walk down that road in this thread. My response would probably be either to point out that all bets are off when working on a poorly designed application or that I never claimed this technique was a silver bullet.
Quote:Original post by stylin
No, and sorry if I sounded rather brash. There's been a few meaningless debates in this thread, and the AP sounded like he wanted to continue in that line.
No problem, I'm easily baited. Didn't mean to wander. [smile]
Quote:
Yes, I can now see why you included this in your rebuttal. But, while education is really the key here, inheritance is essentially an OOP exclusive, and is also highly integrated into the language (I'm referring to C++). I'm unsure if this analogy (with GOTO) is correct.
Well, protected/private inheritance are, to my knowledge, unique to C++. If not unique, then it's at least true that most OOP languages don't include those concepts since they're so similar to aggregates. In any case, I think the analogy is valid for its intended purpose (all analogies fall apart at some point).
Quote:
Another situation in which GOTO is the "best" solution, is where it is impossible, too costly, or not practical to modify the source to eliminate it due to program size (budget/time constraints), team programming styles, conformance with pre-built libraries, etc.
In other words, kludges have a time and a place. I agree. [grin]
Quote:Original post by 999999999
but that breaks stops only the inside loop, right?
And that's why I prefer the goto solution... [wink]
Quote:Original post by Way WalkerFor the third time: that solution actually works!Quote:Original post by 999999999
but that breaks stops only the inside loop, right?
And that's why I prefer the goto solution... [wink]
It's may not be the best one but tweaking the outer loop counter and breaking results in a hackish kind of two-level break.
I always use goto in switch statements,
actuly i forget the real syntax, but it works something like that.
switch(x){case 1:foo();break;case 2:goto case 1break}actuly i forget the real syntax, but it works something like that.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
