From: Stan Moore Newsgroups: comp.os.msdos.djgpp Subject: Re: BREAKing out of a nested loop Date: Sat, 05 Aug 2000 12:11:57 -0400 Message-ID: References: <005a01bffd43$030a3520$0500007b AT brk> <3989d7e4_1 AT news DOT uni-bielefeld DOT de> X-Newsreader: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit NNTP-Posting-Host: digital-1-27.exis.net X-Trace: 5 Aug 2000 12:12:11 -0400, digital-1-27.exis.net Lines: 120 Organization: A Customer of Exis Net Inc To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com On Thu, 03 Aug 2000 20:36:39 GMT, manni DOT heumann AT gmx DOT de (Manni Heumann) wrote: >djgpp AT delorie DOT com wrote: >>>Try 'goto'. You'll love it. They never taught you about it in >>>school. >> >>EEK! There are reasons for this! GoTo is "forbidden"! Nicer is to put this >>into a function >>that returns TRUE/FALSE. So, as soon as a collition is detected, you jump >>out of the >>function with false. This will break the loops. Might be considered cheating >>but it >>helps for making the code more usable so there is a good fix to this >>problem. >> > >Name just one of those reasons agains goto, other then "it looks like >BASIC and real hardcore C coders don't use that kiddy stuff."! > >I didn't yet see one solution in this thread, that was as easy to read >as a simple little goto. Checking a flag for every for, building the >whole nest in a function and return? Picture yourself reading that >code! Goto will also give you the benefit of feeling superior to the >moron who still uses goto after all this years:-) > >Back to the beginning: Name one reason against using goto. At least >name the law the forbids using goto. sure here are a few: debugging maintaining comprehension experience (at this point I'm not counting anymore but it's over 25 years) teaches most, and I am in the group of believers, that goto's are crutches that help get out of a problem you didn't understand well enough to avoid getting in a situation that requires them in the first place. I refrained from jumping into this thread because I didn't have the time to properly address the points I thought needed to brought up. I still don't have time right now and I'll be out of town for a few days due to a family emergency so I won't be able to properly follow this thread. But I will mention that when I first saw this little snippet of code, my first thought was that this was an example from a book on what your code should NOT do. This code is litterally riddled with traps for th;e reader and for the program. Nearly every line could be rewritten to be clearer to read and comprehend, to be easier to maintain, and to debug. The code as it's writen has many points of logical confusion if not outright errors. As one example, look at the two if statements. Each is written with a first test that checks for a value of less than or equal to 0. Then followed by an empty block then comes an else clause that test to make sure the value is Not equal to 0. Since the only value that will fail the first test and excute the second test is greater than 0 the second test is uneeded. By rewriting the first test to read greater than 0 you eliminate the else clause, reduce the amount of code, speed up the program, make it clearer to read and comprehend, and easier to debug. None of that addressed another LITTLE problem. As its written here, this code will always go to FUNCtion no matter what: in other words finding a collision didn't really do anything as far as the target of your proposed "GOTO". If FUNCtion intends on using the detected collision, then there's the problem of getting the location of the collision out of the nested loops. As writen, neither a nor b should exist after the loops are exited. If the FUNCtion doesn't care about the collision, then the entire test seems like it could be eliminated and make things faster, easier to read, and debug. There are quite a few other points, but I'll let these stand for now. In this case a GOTO is merely another warning flag that this section of code needs more attention. The theory of structured programming expresses thae point that complex program flows or multiple paths through a section of code are harder to manage and mentally track. The theory says that one entry point and one exit point fom a section of code allow you to better control the state of the program environment. GOTO's create multiple exits from a section of code and require a programmer to mentally keep track of different exit states from a section of code. In this case the nested loops are used to examine points from (1,1) to (pptest_w, pptest_h). There two possible outcomes possible. Either you find a collision or you don't. As written the normal exit condition of this code is when you don't find a collision and it's unclear what should happen next. The alternative is to detect a collision and then perform FUNCtion(). So one very real posility is to simply move the call to FUNCtion() to the point where the collision is detected. IN other words to call the function from the loops instead of trying to find a way out of the confusing logic and control stuctures to get to the next line of code. Structured programming is not always the best solution and it won't always be the best solution in every case. But it is a very good guideline that captures a lot of programmer experience built from the beggining of programmable computers. To disregard it lightly is to be condemned to relive and relearn history. On the other hand GOTO is not always wrong either, but it is always a flag that something has happened that the programmer can't handle. One use where you continue to see goto's in even experienced programmers code is when something happens that can't be recovered from. Error conditions sometimes call for you to abandon the program logic and head for the nearest exit, literally. Either way a programmer should try to use the lessons learned alreay to avoid making the same mistakes from the past. We need to improve and make entirely NEW mistakes. We owe that to the future programmers :) > >Come on, convince me! In this case, I'd say you might want to convince yourself. Try and improve the code as it's written. Do it with goto's and without and see which one is better for you. Don't forget to go back 6 weeks from now and reread your code to see if the startling clarity you see now is still there. And try to modify the code in a few months. Good luck!