Omnimaga
Calculator Community => TI Calculators => TI-BASIC => Topic started by: MRide on August 09, 2010, 07:48:58 pm
-
Why never to use goto.
(http://imgs.xkcd.com/comics/goto.png)
-
LOL :) That was a good one! Some of my earlier programs use a ton a "gotos". I should be careful to watch out if I will be eaten. :)
-
Man, that happened to me all the time back then, thank god I taste bad
-
lol!
When I was a total noob, I used gotos before I learned about while and repeat.
-
goto has its legitimate uses, though, such as escaping from multiple nested loops in a simple fashion.
-
I love Java's break statement. It changed my life. Before, I would just goto out of the loop.
-
goto has its legitimate uses, though, such as escaping from multiple nested loops in a simple fashion.
Its useful except when it creates memory leaks :P In TiBasic it can have good uses though, i use it a lot in Serenity a lot in the form of massive switch statements, i find its a lot faster then having a ton of If:Then blocks.
-
Lolz, I remember that comic!
-
i think he went a little to far back.
-
In Axe Gotos won't cause leaks fortunately. For massive BASIC programs (and even Axe), it gets hard to follow after a while, though. Also when using them in TI-BASIC, you have higher risks of accidentally causing memory leaks in your programs. I personally stopped using them after I finished The Reign Of Legends 3, in June 2004, with the exception of Illusiat TI-81 Remake, since the 81 has no While/Repeat/For() instruction. I have yet to use them in Axe.
Sadly, those memory leaks were not documented very well back in the days and tutorials on which it was were hard to find, so if you play stuff like Illusiat 11 or 12 or even ROL2, I suggest that you save often, else you can end up with ERR:MEMORY. Just to say how badly documented it was back then, FFTOM series have the game quit completly and tell the user to press ENTER to resume gameplay after exiting menus, before/after battles or even in the middle of battles.
-
You can use Goto \ End \ End to unleak the memory. Just have as many Ends as you have loops or Ifs.
-
I haven't use a Goto in BASIC since I was newb and made a game entirely out of menus. I have used it a little bit in Axe, though.
-
I use Goto all the time. It's pretty useful if you know what you are doing.
-
i use it when i am too lazy to rip apart the code and move something. ie. interrupts.
-
Well one other issue I got with Goto is when you have an extremly large program and a Lbl is located at the complete bottom of the program, it seems to take quite a while to load. If you use them you really need to use them at the right places and properly
-
I use Goto all the time. It's pretty useful if you know what you are doing.
^This.
I still find a use for it, although whenever I use it I just do some checks to make sure no loops are being jumped out of or just kinda force it out (if condition, End, End, End, etc. until you are out then Goto.) I use it to jump back to the top of my code, where I can go anywhere depending on certain variables.
-
I usually write my code so I don't need Gotos.
I've never encountered something that couldn't be reworked easily. (But then, I've not done much coding where Gotos would be useful)
EDIT: 100 posts!
-
The best scenario i use goto in is this. If a goto is called at the very beginning of a program, it can be the fastest way to get to the bottom of the program. When i have large amounts of map data lets say, i have things like this
If T=1:Goto1
If T=2:Goto2
...
Lbl 1
MapData1
Return
Lbl2
MapData2
Return
Horribly memory inefficient, but faster than putting every room inside If:Then Blocks.
-
Hm... that's faster? I'll have to try that out then. coincidentally, I'm actually doing the exact same thing right now.
-
I stopped using Gotos and Lbls once I found an article on BASIC Guru that said it was possible to create games without them. That was.. I don't know, 10 years ago? I made my second game because of that article that used not one lbl or goto.
Simply by using a While loop as a main loop, and utilizing while loops and If:Then conditionals inside that loop, I can maneuver around in a program much faster than any silly Goto/Lbl combo.
The only draw back to coding with While loops in that manner is that the code can get confusing, so you have to take lots of notes on what you are doing, but once you get it figured out, it is worth using. Plus, lack of risking memory leaks is kinda nice. :p
-
I never use Goto's to create loops, only for special jumps or the like. I sometime abuse them within subprograms if i know the memory leak is going to be erased 1 second after it is created :P
-
Sadly, those memory leaks were not documented very well back in the days and tutorials on which it was were hard to find, so if you play stuff like Illusiat 11 or 12 or even ROL2, I suggest that you save often, else you can end up with ERR:MEMORY. Just to say how badly documented it was back then, FFTOM series have the game quit completly and tell the user to press ENTER to resume gameplay after exiting menus, before/after battles or even in the middle of battles.
Yep, I remember those days. The dark ages of TI-BASIC... :P It was odd, because alot of us knew about ERR:MEMORY occuring, we just had the damnedest time figuring out what the hell was causing it, many times which GOTO was the culprit. It's great that so many more things are documented these days and newbs starting out have access to so much good information. :)
-
Sadly, those memory leaks were not documented very well back in the days and tutorials on which it was were hard to find, so if you play stuff like Illusiat 11 or 12 or even ROL2, I suggest that you save often, else you can end up with ERR:MEMORY. Just to say how badly documented it was back then, FFTOM series have the game quit completly and tell the user to press ENTER to resume gameplay after exiting menus, before/after battles or even in the middle of battles.
Yep, I remember those days. The dark ages of TI-BASIC... :P It was odd, because alot of us knew about ERR:MEMORY occuring, we just had the damnedest time figuring out what the hell was causing it, many times which GOTO was the culprit. It's great that so many more things are documented these days and newbs starting out have access to so much good information. :)
it's heros like you guys that figured it out for our gen. :D
-
I try to avoid using goto, but often I'm just too lazy.
Need to get back to a bit at the very start of the program? Whatever, goto. I'm just making dumb little games because I'm bored in class, so what?
-
There's one trick to reduce the slow down caused by Gotos in games. The trick is to put the game main menu at the complete bottom of the code. Start the program with Goto 0, which goes to the menu, and after Goto 0, the game engine and stuff should be there.
-
There's one trick to reduce the slow down caused by Gotos in games. The trick is to put the game main menu at the complete bottom of the code. Start the program with Goto 0, which goes to the menu, and after Goto 0, the game engine and stuff should be there.
interesting, i will do that :)
-
I generally prefer using subprograms and then recalling it it in and then use goto to go to it and loops broken by the goto's that jump back. Like:
:Repeat 1
:Goto A
:End
<code>
:Label A
<subroutine>
:End
-
I generally use them to jump back to the beginning of the code, or like this:
:For(A,0,1
:If Not(A
:Goto AA
:End
<code>
:Lbl AA
<subroutine>
:End
-
The best scenario i use goto in is this. If a goto is called at the very beginning of a program, it can be the fastest way to get to the bottom of the program. When i have large amounts of map data lets say, i have things like this
If T=1:Goto1
If T=2:Goto2
...
Lbl 1
MapData1
Return
Lbl2
MapData2
Return
Horribly memory inefficient, but faster than putting every room inside If:Then Blocks.
It's too bad there's no switch statement in TI-BASIC like there is in C.
-
I don't think I have ever used Goto unless I am creating my own custom menu.
-
The reason Goto is slow when the Lbl is near the bottom of program is because, IIRC, when the parser encounters a Goto it will search the entire program, beginning to end, until it finds it.
In general, though, yeah, Goto is frowned upon as bad programming practice. Its main advantages are optimizations when you really know what you're doing (or, if in ASM, for example, the language provides no other options.)
-
Personally, I don't think labels and Goto's should be considered "bad programming practice". While, yes, they do have their downsides (such as potentially causing memory leaks) and many programmers believe it's better to use While/For/Repeat loops in whatever combination necessary to avoid ever using a label and goto, I don't think we should necessarily call them "bad".
I know from experience that it's often a bit difficult to do things in nested loops rather than with Label-and-Goto and I feel that if we try to push a "gotos are bad programming" sort of agenda, we may end up frustrating new programmers to the point of quitting ("I can't figure out how to do this but I can't use labels and goto's because they'll ridicule/laugh at/hate/whatever me. ARRGH this is too hard, I quit" sort of deal)
@Builderboy Alternatively, put all your map data in a subprogram like this:
if VARIABLE = 1
[matrix] -> MATRIX VARIABLE
so on and so forth...and then whenever you need to change the map, alter the variable and call the subprogram :P
[EDIT] Didn't notice this was a 3 page long thread... my post might be a bit... redundant... `-`;
-
I'm not saying that they are bad to use, and if you feel you must use them, go ahead. ;D
No need to scare away new members :P
-
"BOO!", says goto to lbl.
-
I also remember the days when I used to use Goto all the time. I also ended up having to figure out myself what was causing the TI-BASIC “memory” error on the Z80 calcs. What's ironic is that it actually had the reason listed right in my manuals where the error message was explained, but I ignored it because I misunderstood and thought it was wrong—I thought it meant that any time you use Goto in a loop, it would immediately give that error, which of course it doesn't. :P The fact that it has to be done repeatedly before that happens and the manual didn't make this fact clear caused it to be a long time before I finally figured it out.
This was also around my old DOS QBasic programming days, and I remember causing memory leaks at first by using Gotos in terrible places in my code on that platform, too. :D Later, I discovered how to add debugging code that would print the amount of memory remaining and was shocked watching it decrease steadily the whole time the program ran. In QBasic, it was rarely a real issue, though, because there's so much more memory available on a PC compared to a calc.
Over time, as I read programming books and experimented with different styles, I gradually used Goto less and less. These days, I pretty much never use it at all—it's become natural for me to write code without using it.
There is just one exception currently—in recent C programs (i.e., TIGCC) I do make very occasional use of Goto when dealing with dynamic memory allocation, which is otherwise a ridiculous pain when it comes time to properly free up that memory (especially on the 68K calcs, where nothing cleans up after you and the memory is lost forever until RAM is reset!). Without Goto, I would have to repeat the cleanup code many times everywhere, wasting space and giving countless opportunities for hard-to-reproduce bugs/memory leaks to hide (and making the code actually harder to read). In this particular case, I think Goto is okay because the alternative is far worse.
So I consider Goto as being kind of like alcohol. There's nothing wrong with it as long as you use it responsibly and don't get carried away.
-
good way to put it.
-
I wonder if Goto can cause memory leaks on Casio BASIC...
-
I wonder, I have never had one, are they as bad as ti in some areas? such as Customer care?
-
Hmmm...
:0->A
:Lbl 1
:A+1->A
:While 1
:Goto 1
After the error, (total ram available - program size) / A = ~33.
Why does TI need 33 bytes per while?
-
I wonder, I have never had one, are they as bad as ti in some areas? such as Customer care?
I'm not sure anymore. I heard some bad stuff about Casio that sounded like TI. The good thing, though, is that originally, the Classpad 300 (their touchscreen calc) from 2003 was locked down from ASM dev. The BASIC language was much better than the Nspire right now, but most people in the community wanted ASM/C. Casio responded with a SDK 2 years later, something TI has yet to do with the Nspire.
Casio BASIC speed vs CPU ratio is much worse than TI, though. For example, on their 29 MHz calc, a BASIC For( loop counter will run at the same speed as on the 6 MHz 83+. Some commands are faster on this model, though, like text displaying (which lets you do semi flickerless grayscale).
-
I rarely use in Basic anymore, but I used to. Look at my original version of Numb3rs to see how bad it was! By the time I finished Drifter I was slowly drifting away from Gotos, and Exodus doesn't use any. Gotos, for me, are only good for putting subroutines inside the main program, like player demonstrated on page 2. :)
-
By the time I finished Drifter I was slowly drifting away from Gotos, and Exodus doesn't use any.
Nice use of pun there! :D
EDIT: I mean word play! ;)
-
At school, we have to write these basic programs with terribly unoptimized code.
I know there are situations where the use of Lbl and Goto is inevitable, but all of those programs use the Goto and Lbl commands as like there is no tomorrow.
The programs are so slow that I have a race to see whose optimized code is faster.
-
*ahem*
HOLY NECROPOST BATMAN
well, not really, 'cause it's > 2 months, but that's another story entirely. I wish we even could learn to program at my school.
-
Yes, they try to teach, but
most a few see it as an opportunity to play Block Dude.
-
This topic reminds me how I was forced to use Goto to create loops on the TI-81 due to lack of While/Repeat/For() O.O
-
Wow, the TI-81 was pretty limited. It's sad that TI-81 BASIC is still more capable than Nspire BASIC though. :P
-
At school, we have to write these basic programs with terribly unoptimized code.
I know there are situations where the use of Lbl and Goto is inevitable, but all of those programs use the Goto and Lbl commands as like there is no tomorrow.
Yeah, even though my math teacher actual knows programming, he always, always uses IS<( / Goto instead of a simple For( loop. To keep things simple for everyone else, he says.
-
Wow, I don't think I've ever used IS<(. O.O
-
Casio doesn't have repeat, so it's almost nessecary to have goto to restart the loop from several conditional statements inside of the loop without causing an error (which it will if you use Do-LpWhile or While-WhileEnd
-
Wow, I don't think I've ever used IS<(. O.O
Me neither. IMHO For( is actually easier to understand :P
-
This topic reminds me how I was forced to use Goto to create loops on the TI-81 due to lack of While/Repeat/For() O.O
Like:
0->A
Lbl L
DISP "TRY
A+1->A
If A<100
Then
Goto L
End
Stuff like this?
-
This topic reminds me how I was forced to use Goto to create loops on the TI-81 due to lack of While/Repeat/For() O.O
Like:
0->A
Lbl L
DISP "TRY
A+1->A
If A<100
Then
Goto L
End
Stuff like this?
That reminds me of how I code loops in asm. otherwise in BASIC that's how I coded when I first started using the language.
-
This topic reminds me how I was forced to use Goto to create loops on the TI-81 due to lack of While/Repeat/For() O.O
Like:
0->A
Lbl L
DISP "TRY
A+1->A
If A<100
Then
Goto L
End
Stuff like this?
Probably with IS>(, I'd imagine.
-
I love Java's break statement. It changed my life. Before, I would just goto out of the loop.
++
-
I love Java's break statement. It changed my life. Before, I would just goto out of the loop.
++
Yep. I love the fact that Java doesn't support goto at all but has a break command for when you really need it.
-
Casio doesn't have repeat, so it's almost nessecary to have goto to restart the loop from several conditional statements inside of the loop without causing an error (which it will if you use Do-LpWhile or While-WhileEnd
That sucks. X.x Does Goto cause memory leaks, though?This topic reminds me how I was forced to use Goto to create loops on the TI-81 due to lack of While/Repeat/For() O.O
Like:
0->A
Lbl L
DISP "TRY
A+1->A
If A<100
Then
Goto L
End
Stuff like this?
Probably with IS>(, I'd imagine.
With IS>(, indeed. Here's an example:
0->U
Lbl 1
DispHome
DispGraph
IS>(U,5
Goto 1
That's the equivalent of:
For(Z,0,5
Disp
DispGraph
End
Or maybe it was For(Z,0,4, I dunno...
-
Yes, Goto on a CASIO can leak:
Lbl 1
Do
Goto 1
Ends with a lovely Mem ERROR.
-
Is that really a memory leak, though? You're telling the OS to continually allocate memory for Do statements. It's nothing more than infinite nesting. From what I understand, memory leaks are bugs in the code where the interpreter doesn't properly handle the memory allocations. Your example wouldn't count unless that program somehow terminates earlier than it should.
-
Is that really a memory leak, though? You're telling the OS to continually allocate memory for Do statements. It's nothing more than infinite nesting. From what I understand, memory leaks are bugs in the code where the interpreter doesn't properly handle the memory allocations. Your example wouldn't count unless that program somehow terminates earlier than it should.
His program is an example of what has (incorrectly?) been called a memory leak for a long time in the TI community, but you are right.
-
I'm going to throw in my own two cents.
Goto-Lbl statements are only good when no workable alternative exists. (e.g. subroutines or loops don't exist in the language) For example, While loops in Applesoft BASIC have to be created by IF x THEN GOTO y statements at the end of the loop. Fortunately, this does not create a memory leak, unless you happen to be inside a For loop.
As for TI-BASIC, While loops and If statements can create the effect of a subroutine, but that solution is only for people who want to keep all their code in one program. My game DIE FIEND used this Goto pattern to create subroutines and program branching, but I realized how leaky that code was.
Another alternative is to store your game in multiple subprograms, use an ASM lib to unarchive them (or tell people not to) then ship the game as a group file. That's what I did with Morale, my xLib war game.
And, in Axe, there is virtually no reason for Goto statements at all.
-
I agree with everything except goto statements in axe :P while i think there isn't a common use for them, they can have good uses for optimization, as well as ways to jump out of a large nests of loops.
-
And, in Axe, there is virtually no reason for Goto statements at all.
I think you meant to say
And, in Axe, there is virtually every reason for Goto statements.
:P
-
And, in Axe, there is virtually no reason for Goto statements at all.
I think you meant to say
And, in Axe, there is virtually every reason for Goto statements.
:P
No, I actually meant to say that. True, every reason for a Goto statement exists in Axe, and I can even see using it to break out of loops. But for the most part, I don't use them. I come from a C# programming background, and it is more trouble to program a Goto statement in C# than it is to use something else, such as a Break or Continue statement (That would actually be a cool feature request for Axe!). But in Axe, a Goto statement can serve the same purpose.
-
Axe is so strictly translated to ASM that goto statements (while a bad habit in just about every other language) is almost essential for optimization.
-
Is that really a memory leak, though? You're telling the OS to continually allocate memory for Do statements. It's nothing more than infinite nesting. From what I understand, memory leaks are bugs in the code where the interpreter doesn't properly handle the memory allocations. Your example wouldn't count unless that program somehow terminates earlier than it should.
Well TI-BASIC Goto ERR:MEMORY are refered to as memory leaks too, but I don't know if it's the right term. It just has been widely used for over a decade in the TI community. It sucks Casio also has them...