Gotoless programming
-
The main problem is that goto statement is the only instruction in all programming languages that can change the PC (Program Counter) register in the processor and this is not right
-
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.
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 ifWklyPayDetermined:
TaxDeductible = WorkOutTax(WeeklyPay)
CreateBankTransaction(WeeklyPay - TaxDeductible)
-
If u want speed, i would const the size of for your fixed string, would safe u getting it's length each time u go for another loop in the while. The continues u fire are at end of each if slice, and in an if else construction it would jump out to bottom anyways, so in this case i think continue actually will be equally fast at best and else even slower.
for(unsigned int i = 0; i < StringArray.size(); ++i)
{
if(!stricmp(text+sizeof("other thing ")-1, StringArray[i]))
{
StringArray.erase(i);
break; // or use goto JumpHere?
}
}I normally do different, a bit slower i assume but clear
//somewhere outside the while
const int Sizer = sizeof("other thing ")-1;
//int WalkTo = StringArray.size() - 1;
if (WalkTo >= 0)
{
const char* Check = text + Sizer;
int i = -1;
int Found = 0;do { i++; if (!stricmp(Check, StringArray\[i\])) { StringArray.erase(i); Found = 1; } } while (!Found && (i < WalkTo));}
Okay, let me add a line at the prefix to clear up any confusion:
std::vector StringArray;
The StringArray.size() gets the size of an array of std::strings, not an array of chars. Say the StringArray was initialised to a set of usernames, in a server for example, and the command 2 could be "disconnect xxx".
-
Okay, let me add a line at the prefix to clear up any confusion:
std::vector StringArray;
The StringArray.size() gets the size of an array of std::strings, not an array of chars. Say the StringArray was initialised to a set of usernames, in a server for example, and the command 2 could be "disconnect xxx".
Except that then u might want to retrieve the current size each loop what does it make it different for the rest? I see no different(new) reason to agree break is a good way to be honest.
-
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
returninstead, 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 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.
-
Inspired by the goto comments in the lounge today... Msny years ago a co-worker showed me his first program after we had banned the use of goto statements at our company. His program had a main loop like: If var = 1 gosub 100 If var = 2 gosub 200 and so on.. and inside each subroutine before leaving, it would set var to whatever it needed to be next. An abstracted goto ! This is back in the days before OO and events. This was procedural type code and in this case.. a goto would have been clearly easier to understand.
This is how a feel about goto exactly http://xkcd.com/292/[^]
-
Inspired by the goto comments in the lounge today... Msny years ago a co-worker showed me his first program after we had banned the use of goto statements at our company. His program had a main loop like: If var = 1 gosub 100 If var = 2 gosub 200 and so on.. and inside each subroutine before leaving, it would set var to whatever it needed to be next. An abstracted goto ! This is back in the days before OO and events. This was procedural type code and in this case.. a goto would have been clearly easier to understand.
Anyone who has been around for a long time may remember that the GOTO-less programming controversy was laid to rest (in FORTRAN anyway) by an article published in the December 1973 issue of Datamation magazine. I kept a copy of that article all these years in my humour file as it proposed solving the problem by eliminating GOTO statements entirely and replacing them with the COME FROM statement. Here is an excerpt from the article entitled "A Linguistic Contribution to GOTO-less Programming" (Thanks to the miracle of the internet, the full article can now be found online at this link: http://www.fortran.com/come\_from.html ) --------------------------------------------------------- "This statement causes control to be transferred to the next statement (the statement immediately following the COME FROM) upon completion of the designated statement. Example: 10 J = 1 11 COME FROM 20 12 WRITE (6,40) J STOP 13 COME FROM 10 20 J = J+2 40 FORMAT (I4) Explanation: In this example, J is set to I by state- ment 10. Statement 13 then causes control to be passed to statement 20, which sets J to 3. Statement 11 then causes control to be passed to statement 12, which writes the current value of J. The STOP statement then terminates the program." ---------------------------------------------- In all seriousness, I have not had to use a goto statement in all the code I have written since the day that structured FORTRAN replaced FORTRAN IV on our mainframes in the early 80's. And I am including all the languages I have since used up until today: C, C++, PL/1, Java, C#, VB, Lisp, APL, and JavaScript. It is almost always possible to refactor logic that appears to require a goto into an equivalent form that doesn't. If your nesting is too deep, refactor into shorter, more succinct, and readable methods. Modern IDE's make refactoring dead easy and I have made extensive use of refactoring support in Eclipse as well as Visual Studio. But for any fans of computer history, do yourself a favour and read the entire article at the link above. Apologies for the Canadian (ie. British) spelling of 'humour' and 'favour'. I know they are somewhat anachronistic today, but that was how I was taught.
-
Anyone who has been around for a long time may remember that the GOTO-less programming controversy was laid to rest (in FORTRAN anyway) by an article published in the December 1973 issue of Datamation magazine. I kept a copy of that article all these years in my humour file as it proposed solving the problem by eliminating GOTO statements entirely and replacing them with the COME FROM statement. Here is an excerpt from the article entitled "A Linguistic Contribution to GOTO-less Programming" (Thanks to the miracle of the internet, the full article can now be found online at this link: http://www.fortran.com/come\_from.html ) --------------------------------------------------------- "This statement causes control to be transferred to the next statement (the statement immediately following the COME FROM) upon completion of the designated statement. Example: 10 J = 1 11 COME FROM 20 12 WRITE (6,40) J STOP 13 COME FROM 10 20 J = J+2 40 FORMAT (I4) Explanation: In this example, J is set to I by state- ment 10. Statement 13 then causes control to be passed to statement 20, which sets J to 3. Statement 11 then causes control to be passed to statement 12, which writes the current value of J. The STOP statement then terminates the program." ---------------------------------------------- In all seriousness, I have not had to use a goto statement in all the code I have written since the day that structured FORTRAN replaced FORTRAN IV on our mainframes in the early 80's. And I am including all the languages I have since used up until today: C, C++, PL/1, Java, C#, VB, Lisp, APL, and JavaScript. It is almost always possible to refactor logic that appears to require a goto into an equivalent form that doesn't. If your nesting is too deep, refactor into shorter, more succinct, and readable methods. Modern IDE's make refactoring dead easy and I have made extensive use of refactoring support in Eclipse as well as Visual Studio. But for any fans of computer history, do yourself a favour and read the entire article at the link above. Apologies for the Canadian (ie. British) spelling of 'humour' and 'favour'. I know they are somewhat anachronistic today, but that was how I was taught.
Ok, I lied...I just checked some of my FORTRAN source code written in 1985 and there were a handful of goto statements in 20,000 lines of code. But since FORTRAN, I have not used goto's (to the best of my knowledge :-)
-
Inspired by the goto comments in the lounge today... Msny years ago a co-worker showed me his first program after we had banned the use of goto statements at our company. His program had a main loop like: If var = 1 gosub 100 If var = 2 gosub 200 and so on.. and inside each subroutine before leaving, it would set var to whatever it needed to be next. An abstracted goto ! This is back in the days before OO and events. This was procedural type code and in this case.. a goto would have been clearly easier to understand.
Use a real language Just as a reminder BASIC = BEGINNERS All Purpose Instruction Code
-
Yes, if you're working in a language which doesn't support tail recursion. This goto (and the argument reassignments) should be clearly commented as being a hack around tail recursion not working, though.
Try working on a limited stack-depth platform, such as the PIC16F1516 - your tune will quickly change when you hit the stack depth with your precious function calls. Without goto on that platform you'd be royally f***ed for anything more than the simple. Tail recursion on a PIC: GOTO!
The worst thing about the darkness is the light at the end - DX-MON