Bad programming style
Blitz3D Forums/Blitz3D Programming/Bad programming style
| ||
| Hello, I see BB has the goto instruction. Are there any restrictions on its use. e.g. for x=1 to 10 for y=1 to 20 ; do some processing if <cond> then goto here next .here ; hopefully move onto the next x value & missing rest of inner loop next In other words can goto be used from within 'complex' structures without the program losing track? Thanks Marg |
| ||
| Erm...for that jsut use Exit |
| ||
For i=0 To 1234 For j=0 To 10 If item(i) = True do this Else item(i)=-1 Exit ; don't loop through any more and exit this loop EndIf Next Next -verses- For i=0 To 1234 For j=0 To 10 If item(i) = True do this Else item(i)=-1 Goto myjump ; don't loop through any more and exit this loop EndIf Next .myjump: Next |
| ||
| Usually you can find ways to rewrite a piece of code to avoid using them, but sometimes there's no getting away from the fact that a goto will speed program execution. But yes, there are limitations. You cannot for example, jump in and out of functions. Once you go to a function, you must finish the function or "Return" from it. |
| ||
| wait wait... you can return from a function??? I thought B3D only let you return from a gosub. There really needs to be a book! :] OK that solves several probs I have been having... usually I just goto an exitpoint within the function to end the function prematurely. Kinda like on a date that is going bad! -Rook |
| ||
| Uh, it's called the manual. Or a command reference - read that. =] Function Return variable_name_here Will even give you a return result! |
| ||
| You can goto or gosub from within a loop or a nested decision. But - in the case of a structured loop you have to jump back in where you jumped out from otherwise you will leave orphaned data on the stack. |
| ||
To be clear:Function TheFunk()
for x = 1 to 10
for y = 1 to 10
if x = 5 then return
next
next
End FunctionLeaves nothing on the stack, right? But a goto instead of the return would. |
| ||
| Can we clarify this? I asked about this ages ago and everyone *seemed* to think that Blitz was smart enough to clear the loops off the stack in case of goto... Because, I've been exiting nested loops with gotos like nobody's business. I'm thinking that if it's NOT true, a return would be just as bad. |
| ||
| No, I would have marked the above example as wrong. One should not return/exit/branch from within a loop. Except where you jump back in. I'm not at home so I can't test this but; Function TheFunk() For X=1 to 10 For Y=1 to 10 Goto GoneGoto BRAHERE: Next Next Return GoneGoto: Goto BRAHERE End Function |
| ||
| Seems to limit the use of goto if BB is not clever enough to goto out of loops etc. I think I'll try to avoid using them although it would be nice to use them. Maybe someone technical at BB can clarify. Thanks Marg |
| ||
| Why not write a test program that abuses the problem and see if it blows out the stack? If it's leaving junk on the stack, a pathological test case will blow up pretty quick. |
| ||
| It is totally new to me that a for loop is using the stack. stack is used for nested function calls to find the return adress. For is basicly only a variable and a label including a branch-on-condition command a=0 amax=100 .label ; whatever a=a+1 if a< amax then goto .label the vars are alocated anyway. No stack used as far as I see. What you cannot do and this would leave trash on the stack is when you would leave functions with a goto, esp. when there are nested calls of multiple functions, or even recursive ones. So you soon would have a stack overrun. |
| ||
| There's almost always a way out of a goto. I have done a lot of stuff in blitz and I have never had to use one yet. |
| ||
| I've never used a goto in a Blitz program either. We were taught not to use 'em. |
| ||
| I would have thought the entire stack for the function would be cleared on a return, since it's the normal way to exit a function. Goto could be going anywhere. |
| ||
| any language that even knows of goto can normally not be called "clever" as it is the most destructive command that a programming language ( beside ASM ) can have and often the reason why bugs can't be tracked down or stack overflows happen. |
| ||
| I do not think Blitz suffers from stack problems in this case. It will suffer from recursive function calling though. |
| ||
| We were taught not to use 'em. Yeah, it's age old dogma that really isn't a realistic approach, but every school course that I know of pushes it on the students. Goto has its uses, whether educators want to admit to it or not. |
| ||
| I think it's best to learn how to get away without them first. I still use them occasionally for maximum efficiency. |
| ||
| AlmoAtAcclaim has it! If we branch out of a loop with 'goto' then we hav'nt really left the loop at all. The thing to do is exit each loop (if nested) with `exit` and then exit the function with 'return' Function Funky(StartFrom,FinishAt,Exclude) ;Loop from start to finish ;Exit if loop range includes exclusion value and return exclusion value For xloop=StartFrom to FinishAt IF xloop=Exclude then Exit Next If Not XLoop>FinishAt then Return XLoop End if Return End Function |
| ||
| It is totally new to me that a for loop is using the stack. stack is used for nested function calls to find the return adress. For is basicly only a variable and a label including a branch-on-condition command Actually, I found this argument made good sense. So with any luck, he speaks truth. Graythe, that's all very well and good. But, stuff like this is more of a nuisance to deal with: for x=1 to 100 for y=1 to 10 for z=1 to 5 if (condition) then return next next next Of course, it's possible to get around it. It's just a nuisance. If it's not going to overflow the stack, I'd much prefer to keep on exiting from nested loops the "bad" way. |
| ||
| I think it's best to learn how to get away without them first. I still use them occasionally for maximum efficiency. Oh, absolutely, avoid them if possible but also accept that they have their uses. All I ask is that people don't blindly subscribe to the "never use GOTO, ever!" mantra. Ridiculous. |
| ||
| STONE HIM! STONE HIM! BURN THE GOTO LOVER! |
| ||
| I have to admit, I used to use gotos on the BBC, years ago, but I've never once needed one in Blitz. Nothing against them, it just doesn't come up as something I ever need these days. I guess they can be used for skipping a whole bunch of logic if you know you won't need it on occasion. |
| ||
| The best use of a goto is exiting nested loops. The only other way is to set a flag, exit, check the flag, exit, check the flag, exit..... And keep in mind every single outer loop it has to check the flag every iteration. Plus its alot longer and more confusing. Course, if it leaves behind stack stuff it'd be bad but I highly doubt that. A next statement should know where to return to because it'll return to the same place every time. |
| ||
| Hi Folks, I found it necessary to use goto in the following code: 10 print "Hello World" 20 Goto 10 I wouldn't have got far without that snippet, I can tell you. Later, Jes |
| ||
| I can only repeat: "For" loops do not utilize the stack. At least not if they are coded in a usualy way. Thanks to Anthony for noticing this. BTW. I use Goto to debug. I use it a lot. this way you can skip individual parts of the program easily, without to worry about if/endif nesting. It acts as some kind of multiline remarks. |
| ||
| Back in the days of my BBC,Goto was bad, m'kay? it was slow and i got used to not using it, of course, on the BBC, you pretty much had no choice back then, and cuz it was an interpreter, itd search through ALL of your code just to find the goto point. urgh. bad. Within blitz goto seems much more flexible but still, i rarely use them. Only when temporarily blocking an area of code. I have however on one instance used a nested "goto within a for" loop with no problems and i find it to be quite efficient. i mean, 128 slightly-real cars (on a good graphics system) at 60fps? Fair enough, thats unfair because it depends on the graphics rendering but it was very fast when not rendering Now, thinking.... i looped through each 128 cars, then within that looped through the 128 cars 128 times, each time looping through each of the 128 cars' wheels and suspention objects, doing some nonesence sin/cos etc maths... Bah, im mumbling on again and i dont have any test results so im going to shut up. |
| ||
| err, that must have been one crappy interpreter, unless it was dynamic in other words you can change code on the fly. Otherwise it should be smart enough to remember the mem location of the goto. It shouldn't even be using the text in the first place (tokenize it).... |
| ||
| actually, truth is, it was all tokenised, but it didnt use labels, it only had line numbers. but given the speed of computers back then, searching the memory for line 1020 (actually that always tended to be line 102 but everyone coded in 10s) took a while. the Bbc ruled. its old remember! |
| ||
| searching the memory for line 1020 Somehow I don't think that is how it works, even on an ancient BBC beastie :) |
| ||
| BBC basic was extremely fast. I don't think it searched for a line like that. Sinclair Basic probably did. |
| ||
| i could go into detail of how to do it if you wanted me to my original statement was technically wrong but its interesting Each line of basic started with a line number, and a line length. to find a line all it has to do is read the line number and to get to the next line all it has to do is go forward (n) amount of spaces in memory. it was very efficient but still slow. Its quite amazing how they managed to fit a fully functional version of basic into a rom of about 8k? was it 8k? my memory is rusty there. i also made my bbc talk using two wires, a project lab, a microphone, and some assembler i tought myself. blah blah blah. I still have THREE bbcs in my attic. heh. anyone want one :P |
| ||
| I think it did that to conserve stack. It was a great box the BBCB. |
| ||
| yeah. Anyone still got one? Anyone want to record your voice onto one? ^.^ |
   |