Today, I used goto to double-break out of nested loops
-
I guess I'd move the nested loops into a separate function and called return instead, but that's really goto in disguise anyway :)
That's what I'd have done too. You're allowed to do stuff like that! :)
-
"and I feel fine!" (to say it with R.E.M.)
Agh! Reality! My Archnemesis![^]
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchySo you're the one responsible the north korean attacks today... Shame on you!
-
Mike Hankey wrote:
reduced to writing VB
Oh shiioot... is that what happened? But I swear it was in a
switch! :sigh:PIEBALDconsult wrote:
Oh shiioot... is that what happened? But I swear it was in a switch!
It's like wearing a pocket protector, once your caught wearing it your labeled and there's no turning back.
Artificial Intelligence is no match for Natural Stupidity. http://www.hq4thmarinescomm.com[^] My Site
-
"and I feel fine!" (to say it with R.E.M.)
Agh! Reality! My Archnemesis![^]
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchyIf I had to test your software I would of raized a bug unfortunately. Its against standard. Not following a standard costs money. Might get away with this at your current job but will cost the next company alot of money... E.g. software tagged rev 1.0 unit test fix bugs... goto, 300 occurences. 300 occurences change source code, 300 source files software tagged rev 2.0 unit test 300 source files raize more bugs that was made on fixing "removal of goto's" fix bugs software tagged rev 3.0 unit test outstanding bugs deliver software amounts to $500 000, you just cost the company. have to retrench a few.:~ P.S. !please vote! A computer programmer is someone who, when told to "Go to Hell", sees the "Go to", rather than the destination, as harmful."
"Program testing can be used to show the presence of bugs, but never to show their absence." << please vote!! >>
-
If I had to test your software I would of raized a bug unfortunately. Its against standard. Not following a standard costs money. Might get away with this at your current job but will cost the next company alot of money... E.g. software tagged rev 1.0 unit test fix bugs... goto, 300 occurences. 300 occurences change source code, 300 source files software tagged rev 2.0 unit test 300 source files raize more bugs that was made on fixing "removal of goto's" fix bugs software tagged rev 3.0 unit test outstanding bugs deliver software amounts to $500 000, you just cost the company. have to retrench a few.:~ P.S. !please vote! A computer programmer is someone who, when told to "Go to Hell", sees the "Go to", rather than the destination, as harmful."
"Program testing can be used to show the presence of bugs, but never to show their absence." << please vote!! >>
RudolfErasmus wrote:
P.S. !please vote!
OK, I voted a 3 ;) If the coding standard was "goto is prohibited", I'd follow that. Here, the disgust of goto is big enough that we have about a dozen in over a million LOC (hundreds in 3rd party code, though...) Regarding goto in general: it's a "jump forward", wich does not increase complexity. The typical solutions would be: (a) isolate the inner loop and "hide" the goto behind a early return (if permitted by standards, but requiring single exit makes no sense in C++ anymore). (b) introduce a flag that "bumps" a second break. Now, the first solution is ok to comply with a coding standard, but is complicated if the two loops need a lot of context from the calling function. Even if not, the code compexity is increased, the function needs a contract and additional error chhecking. The second solution increases complexity as well, and makes the code harder to reason about.
Agh! Reality! My Archnemesis![^]
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchy -
RudolfErasmus wrote:
P.S. !please vote!
OK, I voted a 3 ;) If the coding standard was "goto is prohibited", I'd follow that. Here, the disgust of goto is big enough that we have about a dozen in over a million LOC (hundreds in 3rd party code, though...) Regarding goto in general: it's a "jump forward", wich does not increase complexity. The typical solutions would be: (a) isolate the inner loop and "hide" the goto behind a early return (if permitted by standards, but requiring single exit makes no sense in C++ anymore). (b) introduce a flag that "bumps" a second break. Now, the first solution is ok to comply with a coding standard, but is complicated if the two loops need a lot of context from the calling function. Even if not, the code compexity is increased, the function needs a contract and additional error chhecking. The second solution increases complexity as well, and makes the code harder to reason about.
Agh! Reality! My Archnemesis![^]
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchyYeah it depends what you're coding standard says. I do software testing in c(structured programming). Statement such as goto and continue is unstructured. Breaking the code up into smaller functions can help with complexity (if you care about the complexity rating, otherwise complexity in general).:thumbsup:
"Program testing can be used to show the presence of bugs, but never to show their absence." << please vote!! >>
-
"and I feel fine!" (to say it with R.E.M.)
Agh! Reality! My Archnemesis![^]
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchyLet's not forget that one of the goals of well-crafted code is clarity. If a goto helps you achieve more clarity, it's more correct than dogmatically following heuristics as if they were commandments. On the other hand, if your code requires gotos for clarity, it's a sign that there may be other problems, such as methods that are too long. Refactoring (as someone else already suggested) is probably the next step that should be considered in this situation.
-
"and I feel fine!" (to say it with R.E.M.)
Agh! Reality! My Archnemesis![^]
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchy -
I guess I'd move the nested loops into a separate function and called return instead, but that's really goto in disguise anyway :)
Not really. A GOTO doesn't involve a push/pull stack operation so you have to be real careful if you are "gotoing" out of a function or subroutine. You can get away with jumping out of a function only so many times before you get a stack overflow error. Could also cause issues when the program terminates if there isn't very good garbage cleanup. Can you say "memory leak"? You're right about stuffing them into a function call and then using a return to get out, though. That would preserve stack integrity.
-
You're a dirty little pervert! Somewhere Edsger Dijkstra's is choking on a Raise Error statement!
¡El diablo está en mis pantalones! ¡Mire, mire! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF! Personal 3D projects Just Say No to Web 2 Point Blow
The one time I met the respectable Prof E.W. Dijkstra (1977 perhaps), he told me that my wife's piano was out of tune. It was of course, but the remark was both rude and irrelevant. I haven't totally trusted him since then. I have no great love for the absolute adherence to Politically Correct (PC, huummm) programming practices either. If your double-break makes sense and works, then good for you !!
-
RudolfErasmus wrote:
P.S. !please vote!
OK, I voted a 3 ;) If the coding standard was "goto is prohibited", I'd follow that. Here, the disgust of goto is big enough that we have about a dozen in over a million LOC (hundreds in 3rd party code, though...) Regarding goto in general: it's a "jump forward", wich does not increase complexity. The typical solutions would be: (a) isolate the inner loop and "hide" the goto behind a early return (if permitted by standards, but requiring single exit makes no sense in C++ anymore). (b) introduce a flag that "bumps" a second break. Now, the first solution is ok to comply with a coding standard, but is complicated if the two loops need a lot of context from the calling function. Even if not, the code compexity is increased, the function needs a contract and additional error chhecking. The second solution increases complexity as well, and makes the code harder to reason about.
Agh! Reality! My Archnemesis![^]
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchyThe D Language has an excellent feature to avoid this problem. Labelled break:
outer:
while (cond1) {
// ...
inner:
while (cond2) {
// ...
if (cond3)
break inner;if (cond4) break outer; // ... } // ... }This seems elegant to me - of course D also provides a goto, I find it hard to see a reason for that once labelled breaks are allowed - they seem the one fringe case that excuses use of goto's.
-
"and I feel fine!" (to say it with R.E.M.)
Agh! Reality! My Archnemesis![^]
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchyI hope you commented that with: Do not try this at home, script-kiddies. ;-)
-
Let's not forget that one of the goals of well-crafted code is clarity. If a goto helps you achieve more clarity, it's more correct than dogmatically following heuristics as if they were commandments. On the other hand, if your code requires gotos for clarity, it's a sign that there may be other problems, such as methods that are too long. Refactoring (as someone else already suggested) is probably the next step that should be considered in this situation.
Alan Balkany wrote:
If a goto helps you achieve more clarity, it's more correct than dogmatically following heuristics as if they were commandments
That is well spoken. When it happens that more than one branch of a switch Naturally-Shares-Stuff-At-The-Bottom, it has always seemed Clearer to me, to goto L_shared_stuff_for_these_branches. NAMED LABELS are so wonderfully clear, compared to a nameless-break, where you MUST visually scan the close-braces to make your best guess as to where it goes. On 22-nov at 08:52 OriginalGriff remarked that he also was not a believer in the "single exit" - Actually I HAVE come to be a TRUE BELIEVER in the SINGLE-EXIT, unless you can think of some easy way to make the OTHER exits easily SPOTTED. With multiple exits, you need to scan the ENTIRE routine to make SURE you have spotted all the exits. This is in stark contrast to the goto L_shared_stuff_for_these_branches, which actually REDUCES the visual scanning, you can just select the label and do control-F3 to see where it ends up. On 24-nov at 4:00 Rob Grainger remarked on "Labelled break" in the D-Language, which avoids the goto but still does not greatly reduce your visual scanning. To summarize, debate-wise you need to stick the Camel's nose into the tent by finding some classic idiom which is manifestly MORE clear with the goto. None of my code is "classic", so there's work to do there. Having proven that there is at least one case where goto is obviously beneficial, then your "dogma" label really sticks. Because something CAN BE harmful, to ban it, thus eliminating its beneficial uses - why we have reinvented the "Nanny State" !!!
pg--az