|
That sounds like one of my first text-based QuickBasic programs. It was a Tony Hawk menu (to store info about the game, such as cheat codes and areas that were good to get high scores).
Ah, those were the days. A shame I didn't backup the program. Pretty sure it was lost forever when the computer it was on was engulfed in flames from a garage fire my cousin accidentally set.
On second thought, probably best all evidence I ever wrote that was destroyed.
|
|
|
|
|
No, it's always a pity when something like that gets lost. Last year I found my first complete little game. It was written in CHIP-8[^]. I remember that I modified the CHIP-8 VM to relocate the video buffer and some machine language routines outside its tiny 4k address space to free as much memory as possible for the program and the graphics.
My old computer still loaded the tape and I have converted it to binary on my PC. It is now included in an emulator for those old computers. You have made me download the emulator and I have just landed on the moon (in glorious 64 x 32 pixel resolution). Want a screenshot? Here it is![^]
I'm invincible, I can't be vinced
|
|
|
|
|
Looks pretty amazing! Now I want my old Tony Hawk program. 
|
|
|
|
|
Can't be changed, but tomorrow I will turn on the old computer again and search through the tapes for some more old creations 
I remember that there at least was my clone of Asteroids and a Star Wars game where you had to attack those big ATATs. The last one actually used a 'sound card' I had soldered together with an analog sound chip I had pulled out of a broken toy. The same one that's lying on my desk before my keyboard. I have removed it because of the dangerous D/A conversion which could have fried my old computer in no time (but fortunately did not)
I'm invincible, I can't be vinced
|
|
|
|
|
andrewgissing wrote: An abstracted goto !
A switch statement in disguise
|
|
|
|
|
Exactly.
var state = 0;
while(state != 5)
{
switch (state)
{
case 0:
state = 1;
break;
}
}
Interestingly enough C# turns a switch into a set of gotos that use the hashcode of the test value as the jump offset (or something similar). Essentially a hardcoded dictionary - which is why it's so much quicker than repeated 'if's.
He who asks a question is a fool for five minutes. He who does not ask a question remains a fool forever. [Chineese Proverb]
Jonathan C Dickinson (C# Software Engineer)
|
|
|
|
|
Jonathan C Dickinson wrote: Interestingly enough C# turns a switch into a set of gotos that use the hashcode of the test value as the jump offset (or something similar). Essentially a hardcoded dictionary - which is why it's so much quicker than repeated 'if's.
That only happens when dealing with string cases (above some point 3 or 5 IIRC). All others use a jump table.
|
|
|
|
|
Ah, a bit like GOTO DEPENDING
[/Misty-eyed nostalgia for COBOL]
|
|
|
|
|
Actually switch is translated into a bunch of "if" statements.
|
|
|
|
|
/trollattempt?
See: Leppie's comment.
He who asks a question is a fool for five minutes. He who does not ask a question remains a fool forever. [Chineese Proverb]
Jonathan C Dickinson (C# Software Engineer)
|
|
|
|
|
First, the person missed the idea/point. The person should have used a "while" loop instead.
|
|
|
|
|
|
I would also group the break keyword with goto:
public static void renameSchedule(string currentName, string newName)
{
foreach (schedule sched in Schedules.lst)
{
if (sched.scheduleName.Trim().ToUpper() == currentName.Trim().ToUpper())
{
sched.scheduleName = newName;
break;
}
}
}
After all it is jumping out of the looping logic - I use this a lot...
I was taught never to use a goto at university, probably because it would mess up all those nicely drawn diagrams we were creating before we wrote any code, then in the final year when we were doing advanced(cough cough) COBOL programming we were told that there was one instance where we could use it...
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
It's true that break (and continue) are very similar to goto. However, it's also very restricted in scope, and it cannot jump backwards. It cannot jump into the midst of a loop either. That makes it less likely to accidentally break code.
I'm not saying it's good, but it's not quite as bad as goto can be.
|
|
|
|
|
The good old goto debate. A goto is a bit like telling the computer that I don't want you to proceed to the next line of code, instead make some other line the next thing to execute. And we do that all the time: exit for, exit do, if some condition goto next line otherwise goto some other line. While some condition go into first line of loop block otherwise goto past the end of the loop block. And then, it all eventually becomes machine code / opcodes, and all of these become some kind of jump instruction, which is basically a goto. So for all you people out there that think that your code has no gotos, I can assure you the CPU is doing jump instructions left, right and centre as YOUR code runs in the CPU. Now please don't tell me that your code is somehow bypassing the CPU.
The reason this myth exists is that those early versions of BASIC had line numbers for each statement. And you would code "GOTO 760". Problem was when you inserted lines and made 760 line 761 or whatever but didn't go and update everything pointing to 760. And so this caused problems and bugs. Let's move on. We have alphabetic statement labels (used all the time in assembly language by the way), so you can now "Goto SomeLabelThatHasAMeaningfulNameThatWontBeRenumbered" and the problem is gone. Use goto freely, it's OK. I do it. It gets me out of deep nested rules and condition logic where I have established something I needed to establish. Yes there are always other ways to achieve the same result, but no - they are not always better or more elegant. And now it is time for me to go to bed.
|
|
|
|
|
Umm, as you said goto caused problems if you used it and didn't really know how it worked. The thing is most (if not all) programs are compiled and this causes the assembler to move all the loops, functions anything else to the old loveable JMP or Jump statement (which is a go to this location). (Complains about "Softies not know how work things", burn hand on soldering iron!)
|
|
|
|
|
The reason not to use goto is not a technical one, but a code cleanliness one. A goto is an unstructured jump and makes it much harder for a human brain to comprehend the structure of the procedure. Loops with breaks and continues, conditionals, switch blocks and so on may translate to jump instructions in assembler or IL, but they're structured and therefore easier to understand.
The only time I would say it might be okay is the 'double break' (i.e. breaking out of a 2D or deeper loop set). When your logic is this complex it's usually better to take the looping code out into a sub-procedure or -function and use return instead, because chances are that procedure is too long already. (You can always ask the compiler to inline it if you think the function stack is critical.) In modern languages, proper error condition handling (i.e. exceptions) have taken away most of the situations in which you'd want to do this.
So I agree up to a point: fundamentalist 'never' dictums (dicta?) are not particularly helpful. But it is very rarely the most elegant approach to use a goto.
|
|
|
|
|
The most common argument I hear from experienced programmers is that a goto is a convenient way to jump around in an eight level nested loop.
This tells me they have mastered the function call yet.
But I can see how gotos can make it easier to navigate spaghetti code.
|
|
|
|
|
The point I was making was: use Goto when it is good to do so. That's a matter of judgement. It probably won't be often. But use it freely when you consider that it works well - when it simplifies or clarifies the logic flow. Don't be religious about following some rule that you heard somewhere. "Shoulds", "don'ts" and "nevers" are a poor substitute for judgement.
The fool knows the answer, the wise man thinks.
|
|
|
|
|
This is a simplistic example of the sort of thing I am talking about. My sympathies to those of you who find it un-structured, hard to understand, un-clean or bad code. Let me see yours.
if WageEarner then
WeeklyPay = HrsWorked * Rate
Goto WklyPayDetermined
end if
if SalaryEearner then
WeeklyPay = (Salary * 7) / 365
Goto WklyPayDetermined
end if
if FutureHire then
WeeklyPay = 0
Goto WklyPayDetermined
end if
if Retired then
if WasWageEarner then
WeeklyPay = FinalRate * 40 * 0.5
Goto WklyPayDetermined
else
WeeklyPay = 0.6 * (Salary * 7) / 365
Goto WklyPayDetermined
end if
end if
WklyPayDetermined:
TaxDeductible = WorkOutTax(WeeklyPay)
CreateBankTransaction(WeeklyPay - TaxDeductible)
|
|
|
|
|
I've seen justifiable GOTOs in C code. Usually, the scenario involves nested control structures (IFs or loops) and the possibility of a trash-it-all error deep in the nest. C++ offers less of an excuse for GOTOs, because of the ease of use of the exception mechanism.
That having been said, if a programmer feels he can defend his use of a GOTO, and his program is otherwise legible and maintainable, it's usually not worth starting an RWAR over it. That is, unless you enjoy RWARs for their own sake!
(This message is programming you in ways you cannot detect. Be afraid.)
|
|
|
|
|
andrewgissing wrote: Msny years ago
Years before MSN, you mean? 
-= Reelix =-
|
|
|
|
|
The gosub call was the mechanism for calling faux functions / subroutines.
Unlike the goto, the last address was pushed on the stack so the subroutine could return to the location it was called from.
They were a big improvement over goto.
|
|
|
|
|
You should try to rewrite that code with goto statements instead of gosub, and see what you get. 
|
|
|
|
|
Gosubs were used alot in the old days when programming in GWbasic and basica. think the time I used them was in dos 2.11
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
