Page 1 of 1
Replacement for GOTO command
Posted: Mon Oct 27, 2003 1:14 am
by Banaticus
Code updated For 5.20+
This is continued from
my previous topic in the Beginner's forum. I'm sure that you people here know this already, but it sure seemed like a great trick to me.
Thanks!
I made that change and then noticed that I'd created a never-ending loop, as I never again declared do_over to be equal to 0 again. I rewrote the code, but I was having trouble breaking off the number matching early. If, for example, J was 93, and the random number matched the first number in the array, I didn't want the whole array checked. I wanted the check broken off and a new random number created, and the whole process started again.
Without a GOTO command, this seemed too difficult and I at first wrote the following:
Code: Select all
Dim long_array.b(94)
For J = 0 To 93
While long_array(J) = 0
random_number=Random(93) + 1
do_over = 0
For K=0 To J
If random_number = long_array(K)
do_over = 1
EndIf
Next K
If do_over = 0
long_array(J) = random_number
EndIf
Wend
Next J
But then I realized that a Return command from a subroutine could be nestled within an If/Then statement, and that this could provide the same functionality as a GOTO statement. So I wrote the following. It includes comments, and is the version that I'll post on my website (as soon as the blackout is over and the DNS Engineering, Inc. (my host) servers are back up.
Code: Select all
;Arrays may not be declared on the fly, but must be declared before they are called.
;Because I know that I will only be useing 94 numbers, I've used a .b, or bit array.
;The ".b" tells the program what type of array it will be -- I won't need to type it again.
Dim long_array.b(94)
;This is the part that creates a random number
;It calls a function that is found at the end of the program.
;Note my use of Repeat commands nestled in the function as a
;replacement for a GOTO command.
For J = 0 To 93
Repeat
do_over = 1
random_number=Random(93) + 1
Gosub random_match
Until do_over = 0
long_array (J) = random_number
Next J
;This is used to view the array
;It displays 25 numbers on each line.
OpenConsole()
For K=0 To 24
Print(Str(long_array(K)))
Print(" ")
Next K
PrintN("")
For K=25 To 49
Print(Str(long_array(K)))
Print(" ")
Next K
PrintN("")
For K=50 To 74
Print(Str(long_array(K)))
Print(" ")
Next K
PrintN("")
For K=74 To 93
Print(Str(long_array(K)))
Print(" ")
Next K
;My standard "end of program" text
PrintN("")
Print("Press 'Enter' to continue")
pause$=Input()
CloseConsole()
End
;random number matching function
;This is where I got my "GOTO" equivalent.
;If the random number matches a number used already, the
;function terminates early, without declaring ;do_over = 1
;Thus. the Repeat/Until loop continues to create a new
;random number and to call this function again until a unique
;number is found.
random_match:
For K=0 To J
If random_number = long_array(K)
Return
EndIf
Next K
do_over = 0
Return
Posted: Mon Oct 27, 2003 2:04 am
by blueznl
how about this solution?
Code: Select all
z_size = 94
Dim z.b(z_size)
For x = 0 To z_size
z(x) = x
Next x
For x = 0 To z_size
y.l = Random(z_size)
t.b = z(x)
z(x) = z(y)
z(y) = t
Next x
Killing Off GOTO is Already A Dead Issue
Posted: Mon Oct 27, 2003 5:27 am
by oldefoxx
Branching code allows you to create different methods for dealing with variances. The problem sometimes arrises of having the code merge again so that you can continue to carry out common processes.
A dispute arrose some years ago about whether GoTo statements were a good way to bring about this merge effort or not. One of the problems was that in Interpretive code, some loop structures, particularly the For/Next loop and the associated variable, were carried on the stack. Jump to the wrong place, in or out of a For/Next loop, and you could misconstrue the contents of the stack and cause a catastrophic failure to your program.
Several people took it as a mission to show how you would write "good" code that avoided the use of the "bad" GoTo command. It became a mantra that the best programmers would never use a GoTo command.
The observation was flawed, the circumstances are entirely different in a modern compiler, and the determination of what is "good" and "bad" in terms of programming practice is a rediculous on the face of it. A good programmer is one that achieves his or her objectives, no matter the means or method. A great programmer is one that can do it on time, under budget, and push the envelope in the process. Pushing the envelope would not include listening to anyone who repeats "Don't ever use GoTo statements in your programs, it is a bad practice!" If the circumstances warrants using a GoTo, then do it. Don't waste your time trying to come up with some other method and convoluting your code in some meaningless or ineffectial manner just to satisfy someone that hasn't the wisdom to reason this out for themselves.
The best programmer I ever knew used only about 15% of the available commands, but he wrote some fantastic programs that pushed the envelope all over the place. I used over 97% of the instruction set, and while I had the presumption of rewriting some of his code to make it more concise, I could not improve on his approaches or algorythms. It took me years to realize that there was a certain elegance and simplicity to his approach, and that I was not near as good as I had believed I was. All I did was stroke my own ego by "upgrading" his code to my level, but that was a waste of my time, and totally unnecessary. If a GoTo will do it, the go for it, and forget the so-call purists that presume to lecture the rest of us on how the job should be done. Heck, some purist argue that the only proper way to program is in assembler, and others argue you cannot write a decent program unless you write it with C/C++, and others abhor the reliance on Windows and insist that we will not have a programmer's paradice until Linux or Unix dominates everywhere. Believe what you will, but please stay out of my face.
This is a dead issue.
Re: Killing Off GOTO is Already A Dead Issue
Posted: Mon Oct 27, 2003 6:08 am
by PB
> If the circumstances warrants using a GoTo, then do it.
Very true. In fact, I have some code in one of my apps that simply cannot
be done without a GoTo command. It's too long to post here, but there's
absolutely no other way to do my routine without it, and I've tried. GoTo
is not as evil as some people want others to think.
Posted: Mon Oct 27, 2003 10:25 am
by Fred
Goto IS evil
Posted: Mon Oct 27, 2003 10:26 am
by dmoc
but please stay out of my face.
Is that an invitation for constructive criticism?
Seriously, I'm in agreement almost 99.99% So close it's scary. I even thought I was reading something I wrote. I would add that if "goto" was such a no-no then CPU's would have already undergone a radical redesign, which they haven't. Still, I *do* think intentional avoidance of "goto" generally leads to better design methodology (skills, approach, call it what you want) but this does not imply the pathalogical avoidance that some programmers and language designers subscribe to. As for specific languages I think it's very much a horse-for-courses thing, each has it's place. OOP is a definate for large projects but I think it has been oversold for small and medium projects.
I suspect that at some point in the future someone (prob MS) will come up with a design methodology and language that, for the average person, will take more than a useful lifetime to become "proficient" in. Programming will then be a religion with no other purpose except the endless, pointless and ultimately unattainable search for perfection. No doubt there will be the "Golden GoTo" sect and many others all battling it out for world domination. Yawn... back to bed I think
Posted: Mon Oct 27, 2003 12:33 pm
by waffle
i think once you get into speed optizers and ASM, the simple goto begins to look pretty good.
But should be avoided in higher languages to permit the compiler to use asm jumps to optimize.
also, a goto is sometimes the simplest way to skip code before the end of a main loop....
do
some code
if this happens then goto loopend
more code
loop
sometimes neater than if-then-else-elseif-endif
Posted: Mon Oct 27, 2003 2:23 pm
by Fred
To break loop, 'break' is THE way to go (and not go to
) : it keeps the stack consistent if need or behave exactly like a GOTO.
Posted: Mon Oct 27, 2003 10:03 pm
by Banaticus
Fred wrote:To break loop, 'break' is THE way to go . . .
What is Break? I cannot find it in the PureBasic help file. Neither Index nor Search brings up anything on a Break command.
Posted: Mon Oct 27, 2003 10:44 pm
by freedimension
Banaticus wrote:Fred wrote:To break loop, 'break' is THE way to go . . .
What is Break? I cannot find it in the PureBasic help file. Neither Index nor Search brings up anything on a Break command.
You gotta have version 3.8. It's a very new command.
Posted: Tue Oct 28, 2003 4:02 am
by Banaticus
Thanks.
I downloaded and installed 3.8, so that I could remove that subfunction and use the Break command instead, but I'm faced with a new problem now. My code no longer works now that I've installed 3.8. You can read my post on it
over on the Bug forum.