Absolute need of goto 4 correct functioning of loop routine.

[Nemesis]

Common sense programming knowledge tells me this would not be possible, you can always, if you plan it out use an alternative to GOTO to exit or complete a correct funtioning looped routine.
(The term, Correct functioning here means to complete the intended task of the written routine). Now, if nobody can come up with any validated entries, in QB ofcourse... then maybe post a routine which GOTO is the absolute most efficient command to use
in a looping type routine. One thught of GOTO being the most efficient way was na_th_an's post, (I believe it was in the projects section of this forum), about using it to exit a nested loop, instead of perhaps using multiple exit loop commands.
I'll post my entry but, I'll need to dig it up first....

Let the challenge begin!

[Meg]

I'm going to go crazy with this GOTO argument. The fact that people have to try this hard to come up with an example of when GOTO makes sense to use--and then inevitably come up with the same example--speaks volumes to the utility of this command.

Proper code-planning negates the necessity for this command. GOTO is a logical nightmare to the program-flow; it sections off parts of your flowchart plan from the rest of it by interrupting the program flow and redirecting it to another part of code.

GOTO can be used by a careful coder in very specific instances to replace the logic that can be achieved by other commands whose purpose is to do exactly that, to save you a comparison or two in code segments that are unduly complex, such as a multiple-nested FOR loop with commands immediately following each NEXT statement, so that stacked NEXT isn't possible. Wow, that was a run-on sentence. :o

So if you write a complex bit of code like this, just to prove to people that GOTO is a "necessary evil", you can do it. But the code that you'll end up writing is something that is likely unnecessarily complex, and just invented to show off the use of GOTO.

Na_th_an brought up an interesting point in his last post on this subject: use of GOTO to optimize the speed inside a calculation-heavy loop. I do feel that in most instances, a nested loop structure built around use of GOTO at the exit condition would be better off scrapped, re-planned, and re-written. But then, I've not written many programs to the levels of complexity that Na_th_an has, so I think his opinions on this topic are likely more valid than my own.

This example, which I keep seeing:

[syntax="QBASIC"]
FOR x1% = 1 TO BigNumber1%
FOR x2% = 1 TO BigNumber2%
FOR x3% = 1 TO BigNumber3%
FOR x4% = 1 TO BigNumber4%
IF (exitcondition) THEN EXIT FOR
NEXT x4%
IF (exitcondition) THEN EXIT FOR
NEXT x3%
IF (exitcondition) THEN EXIT FOR
NEXT x2%
IF (exitcondition) THEN EXIT FOR
NEXT x1%
[/syntax]

can be simplified to:

[syntax="QBASIC"]
FOR x1% = 1 to BigNumber1%
FOR x2% = 1 to BigNumber2%
FOR x3% = 1 to BigNumber3%
FOR x4% = 1 to BigNumber4%
IF (exitcondition) THEN EXIT FOR
NEXT x4%, x3%, x2%, x1%
[/syntax]

You can further complicate the already-intimidating structure by throwing in commands between the NEXT list, which renders them unable to stack. In this case I either: 1. don't use FOR loops, 2. am already using SUBS to block off pieces of logically relevant code (as, at this point, the code is already being rather horrendous) which makes the whole argument a moot point, or 3. trip the exit condition by adjusting the comparison variables inside the inner-most loop. In fact, I typically prefer these methods to EXIT FOR itself.

Why? Because when you start a FOR loop, you are writing a looping structure that has a built-in exit condition. That's what the FOR loop is there for: To execute a piece of code an exact number of times. When I look at something that says:

Code:

FOR i% = 1 TO 10

I expect the loop to run 10 times, and for i% to equal 11 when it's done. If you're kicking out of the structure before this exit condition is met--either via GOTO, EXIT, etc--maybe you shouldn't be using a FOR...NEXT loop in the first place. Personally, I like to see the exit condition of a loop met to make it stop running, if at all possible.

In my experience, I've never encountered a situation where use of GOTO made the most sense. I've always been able to refactor the program in a more logical way which didn't necessitate use of GOTO.

I find this interesting reading: http://c2.com/cgi/wiki?GotoConsideredHarmful

That example looks familiar. >.>

*peace*

Meg.

[Z!re]

Theres some book or whatever, called "Goto considered harmful"

There's also a counter book:
"'Goto considered harmful' considered harmful"

Or something.



1) No matter how you do it, you'll always use GOTO
2) It's not your code
3) You and him are not in some coding group togheter


If your code is only to be viewed by yourself, and perhaps a few others for help, then use whatever you want.

If you are part of a larger group, then code clean, so the other persons can easily get into the code and figure it out.

This whole argument is stupid.

Goto is as valid as using Let, it's just a coding style.
Don't like it, don't bother with it, I don't bother with GOTO code unless it's on a topic that really interesst me (and bowling isnt one of those)

And:

Code:

PRlNT = 100

Code:

LET PRlNT = 100

Code:

PRINT PRlNT

[na_th_an]

Meg, you are still losing my point: optimization. GOTO may be faster. It depends on the kind of coding you are doing.

It looks like I use 20,000 gotos per program, but in fact you can't hardly see more than 1 or 2 per 3,000 lines of code.

It's just that: when you need speed, you can lose a lil' bit of readability.

Plus, seriously, I just didn't know that EXIT FOR exitted all the nested FORs. I thought that it just exited one.

I expect the loop to run 10 times, and for i% to equal 11 when it's done. If you're kicking out of the structure before this exit condition is met--either via GOTO, EXIT, etc--maybe you shouldn't be using a FOR...NEXT loop in the first place. Personally, I like to see the exit condition of a loop met to make it stop running, if at all possible.

Exactly what I posted in the other post. The correct construction, if you need to exit a FOR loop, is to make a DO:LOOP or a WHILE:WEND with a correct exit condition. My point back there was that breaking from an apparently "closed" structure (a FOR:NEXT is supposed to loop a fixed number of times) with a GOTO or with an EXIT FOR is just the same: bad. The EXIT FOR/WHILE/DO/FUNCTION/SUB/FN stuff is there 'cause some funky thinker in the microsoft team. My point is that breaking from a for loop, sub, function, while... etc is "bad practice" by itself, exactly as bad as using GOTO. Notice that the EXIT blah stuff looks cleaner, but in fact it's the same: you are suddenly breaking from a loop. That's why I didn't understand why you defended EXIT and dismissed GOTO. If you tell me "it's just for cosmetic coding" I have to agree, but logically it's the same.

Why do you want to exit suddenly from inside a loop? for speed. Can it be overcame using structural programming? of course. Is it always slower? not at all, sometimes it will be slower, sometimes it won't. But it may look less readable at times.

For example, you can avoid EXIT FUNCTION using IFs intelligently in your FUNCTION. But it may look bloated. Sometimes placing an EXIT FUNCTION may help you having less code. Sometimes it will look better, sometimes it won't. See what I mean? Readability and cosmetic coding is awesome when you are teaching someone, and I already stated that I'm with you when it comes to show newbies how to code, and that I understand that you may feel with some kind of "responsability" over them, 'cause I've also felt that way sometimes that people have suggested to use GOSUB, inter-module globals or something like that. But when you are coding for yourself, a little bit of dirty optimization can gain you a few more fps

Also, what you say about calling SUBs to isolate logics looks good and organized, but everytime you call a SUB you waste time and memory.

Which such kind of optimization we made our last project from college process a sound signal with a simulated ADSP21 microprocessor take half of the time it took without it. The simolator core is horrid, absolutely ugly, but when you need speed you notice that unrolling loops or replicating code works.

What I mean is that many times we say "GOTO is bad" without stopping a little to think that many of the "alternative features" of QB are as bad... or as good.

[Meg]

I did make note of your optimization argument, above. Fortunately, I've never had the headache of writing a program that suffered from speed issues to the point that including a GOTO statement would significantly improve speed (but no other refactoring technique could). But then, I haven't written very many compound/nested loop/command-heavy programs. I've always found another way. So I'm not really qualified to comment on using GOTO for optimization.

As far as EXIT FOR: Technically, it transfers program flow ahead to the line immediately following the first NEXT command it encounters. So if you can stack your NEXT statements, you can EXIT FOR them as a block.

If you are processing commands in between your NEXT statements, then you obviously can't stack them, and therefore you can't EXIT them as a block. In this instance, I'd either:

1. Set the conditional variable in the inner-most loop, and have it calculate its way out, or

2. Block logically-related inner loops (ones with identical exitcondition) into a SUB, and call the SUB from the outer loop (which we don't want to kick out of). Then you can terminate the SUB to cease internal loops, and program flow will continue on with the outer loop.

*peace*

Meg.

[na_th_an]

Sorry, Meg, I was editing my post to add some stuff I forgot while you posted yours. Please, I beg you to read the added parts

The saying isn't false: everyday you go to bed having learnt something new I didn't know the for stuff at all. Now allowing multiple variables in a NEXT makes sense.

[Nemesis]

I'm going to go crazy with this GOTO argument.
The fact that people have to try this hard to come up with an example of when GOTO makes sense to use

Ummm, read the challenge topic again Meg, I said come up with an example of when GOTO is absolutely necessary to use, not when GOTO makes better sense, (a big difference).

Proper code-planning negates the necessity for this command. GOTO is a logical nightmare to the program-flow; it sections off parts of your flowchart plan from the rest of it by interrupting the program flow and redirecting it to another part of code.

I'm going to go crazy myself now We've all been through this before, hence the reason I proposed this challenge... to maybe prove that GOTO actually has its spot among the legitamite
commands. (Besides the ones which actually aren't legit, eg..LET)

GOTO can be used by a careful coder in very specific instances to replace the logic that can be achieved by other commands whose purpose is to do exactly that, to save you a comparison or two in code segments that are unduly complex, such as a multiple-nested FOR loop with commands immediately following each NEXT statement, so that stacked NEXT isn't possible. Wow, that was a run-on sentence. :o

GOTO EXAM #10101001.AAC4...

Get your #2 lead pencils ready...

#1: T or F, goto should never, ever, be used or even discussed?
#2: T or F, goto should only be used in certain coding situations?
#3: T or F, goto should be used as much as any other command?

Too many people with too many contradicting views is what I see :-?

So if you write a complex bit of code like this, just to prove to people that GOTO is a "necessary evil", you can do it.

Really?
Then lets see your necessary GOTO submission

But the code that you'll end up writing is something that is likely unnecessarily complex, and just invented to show off the use of GOTO.

It can be complex, as long as it's less complex than using the supposed innovative, modern, non-spaghetti, clearer, structured
style commands that have made GOTO supposably obsolete in modern programming practices. :rotfl:

Na_th_an brought up an interesting point in his last post on this subject: use of GOTO to optimize the speed inside a calculation-heavy loop. I do feel that in most instances, a nested loop structure built around use of GOTO at the exit condition would be better off scrapped, re-planned, and re-written. But then, I've not written many programs to the levels of complexity that Na_th_an has, so I think his opinions on this topic are likely more valid than my own.

Yeah but, again it's something that's been discussed throughly, and a program to that effect wouldn't fit the challenge but, would work for the alternative challenge I mentioned.
(We all could come up with clever code for the second one though.)

When I look at something that says:

Code:

FOR i% = 1 TO 10

I expect the loop to run 10 times, and for i% to equal 11 when it's done. If you're kicking out of the structure before this exit condition is met--either via GOTO, EXIT, etc--maybe you shouldn't be using a FOR...NEXT loop in the first place.

Sure, me too, although that's irrelevant...
See that's why I said a looped routine as apposed to a FOR NEXT looped routine. (I wasn't specific because, if you want to try a FOR NEXT loop, then by all means go right ahead )

Personally, I like to see the exit condition of a loop met to make it stop running, if at all possible.

Lost you there...
Don't know if that's what you actually mean but, I could think of many. (Conventional methods, and must I say, even... GOTO :lol

In my experience, I've never encountered a situation where use of GOTO made the most sense.

You've posted situations, and even are encountering these situations while reading this post :???:
Now you are even contradicting yourself.
You sure you haven't already gone crazy, Meg?

I've always been able to refactor the program in a more logical way which didn't necessitate use of GOTO.

Great, then you might be of some use after all for this particular challenge...
When a submission is entered you can see if a more logical or valid way exists, using a method other than GOTO :bounce:

I find this interesting reading: http://c2.com/cgi/wiki?GotoConsideredHarmful

I didn't really... just more contradictions.

Anyways, hope I wasn't sounding like a smart-arse, if I did sorry, don't take it personally.

Laters.

Nemesis

[Nemesis]

Plus, seriously, I just didn't know that EXIT FOR exitted all the nested FORs. I thought that it just exited one.

Heh, I actually knew that but, somehow forgot about it when I mentioned about na_th_an's example.

Heh, yes I even sometimes find myself... re-learning things.

Good point to mention that Meg :king:

Cya!


Nemesis

[Meg]

<joke>Now, see, Na_th_an and I were having a good discussion about GOTO and you had to go and get all snippy with me. :D </joke>

I'll be the first one to offer my opinion: This challenge cannot be done. Heck, I'll go one step further: I postulate that *NO* command in QB is "necessary" to do a task.

[adosorken]

Oh pulease people...sheesh why didn't I see this post earlier...stop arguing over GOTO already. It's like arguing over religion. :roll: