[go: up one dir, main page]
|
|
Log in / Subscribe / Register

Re: There would be precisely as many "goto" statements

Re: There would be precisely as many "goto" statements

Posted Dec 25, 2014 23:07 UTC (Thu) by ldo (guest, #40946)
In reply to: Re: Wouldn't it be simpler and more readable to use a goto instead of a pseudo-loop? by mchapman
Parent article: The "too small to fail" memory-allocation rule

And you would need a different label for each. And the extra visual burden of ensuring that each goto is paired with the right label. Which is unnecessary with a break, since that can only ever terminate one enclosing construct.

And the further burden of getting things wrong when you try refactoring the code.

Like I said: NO GOTOs!

to post comments

Re: There would be precisely as many "goto" statements

Posted Dec 26, 2014 0:01 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (5 responses)

Except that NOW you have an extra burden to check that break actually breaks out of a right loop.

So, YES to gotos for error handling!

Re: So, YES to gotos for error handling!

Posted Dec 26, 2014 0:37 UTC (Fri) by ldo (guest, #40946) [Link]

Put your money where your mouth is. You have my code; go rewrite it!

Re: There would be precisely as many "goto" statements

Posted Dec 26, 2014 7:38 UTC (Fri) by epa (subscriber, #39769) [Link] (3 responses)

Perl allows 'last' (its equivalent of 'break') to take a loop label. That would be a useful enhancement to C.

Re: There would be precisely as many "goto" statements

Posted Dec 26, 2014 7:43 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

That's a different issue - exit from multiple nested loops. In languages lacking labeled loops (C, C++) it's often a place where 'goto' is used.

Re: There would be precisely as many "goto" statements

Posted Jan 16, 2015 5:10 UTC (Fri) by CameronNemo (guest, #94700) [Link]

Rust got that recently. It is interesting, but a little strange/complicated.

Re: There would be precisely as many "goto" statements

Posted Jan 16, 2015 18:23 UTC (Fri) by zlynx (guest, #2285) [Link]

Whenever I got to wanting labeled blocks in C, I sat down (OK,really I was already sitting down) and decided to add another function instead.

That almost always made the code cleaner, and let me exit the block (which was now a function) with a simple "return."

Re: There would be precisely as many "goto" statements

Posted Dec 26, 2014 7:34 UTC (Fri) by WolfWings (subscriber, #56790) [Link] (19 responses)

Um... since when?

if (error1) {
  goto label;
}

/* ... more code ... */

if (error2) {
  goto label;
}

/* ... more code ... */

label: free(pointer);

You can use a single label for any number of goto's, so each label is specifically describing it's use case (freeAndExit perhaps, or whatever semantic name you want to give it) and there's no more/less lines than your do{}while(false); construct but copy-pasting code inside/outside the strcture can't break it as easily.

Just saying you're wrong about the claim of needing a billion labels, goto is many-to-one not one-to-one in that regard.

Re: you're wrong about the claim of needing a billion labels

Posted Dec 26, 2014 21:15 UTC (Fri) by ldo (guest, #40946) [Link] (17 responses)

Fine. Try reworking the example I gave above, then. That has allocations nested up to three levels deep, as well as loops. See how well that works using GOTOs.

Re: you're wrong about the claim of needing a billion labels

Posted Dec 27, 2014 0:47 UTC (Sat) by reubenhwk (guest, #75803) [Link] (7 responses)

GOTO statements are fine. I like them and find it leads to cleaner, easier to understand code. The speghetti code thing is a myth with plenty of examples to disprove it in the Linux kernel.

The deeply nested allocations example *should* be solved by factoring out local/static helper functions...In other words: if your code is too complicated to use GOTO's properly for cleanup, then your code is too complicated.

Re: deeply nested allocations example *should* be solved by factoring out

Posted Dec 27, 2014 20:42 UTC (Sat) by ldo (guest, #40946) [Link] (6 responses)

Fine. I have offered my example; feel free to rewrite it to prove your point, and then we can compare.

Re: deeply nested allocations example *should* be solved by factoring out

Posted Dec 27, 2014 20:56 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

I rewrote a sample. It's shorter and easier to read and understand. I provided you a sample of non-trivial cleanup logic from a big project.

What else do you want?

Re: What else do you want?

Posted Dec 27, 2014 21:33 UTC (Sat) by ldo (guest, #40946) [Link]

An example that proves that you can deal gracefully with all the cases that my code manages.

Re: deeply nested allocations example *should* be solved by factoring out

Posted Jan 1, 2015 0:27 UTC (Thu) by reubenhwk (guest, #75803) [Link] (3 responses)

Please keep an eye out for pull requests...

https://github.com/ldo/dvd_menu_animator/pull/2

Re: deeply nested allocations example *should* be solved by factoring out

Posted Jan 1, 2015 4:23 UTC (Thu) by flussence (guest, #85566) [Link] (1 responses)

Methinks the crank is polishing his résumé to go apply for GNOME commit access.

Re: deeply nested allocations example *should* be solved by factoring out

Posted Jan 1, 2015 4:40 UTC (Thu) by reubenhwk (guest, #75803) [Link]

Is there an open position?

Re: deeply nested allocations example *should* be solved by factoring out

Posted May 23, 2017 13:10 UTC (Tue) by mirabilos (subscriber, #84359) [Link]

Interestingly enough, this got *deleted* (probably by ldo?).

goto bike shed

Posted Dec 27, 2014 17:44 UTC (Sat) by itvirta (guest, #49997) [Link] (8 responses)

> No! No GOTOs. They don’t nest easily, and they lead to spaghetti code. Look at the
> example code I linked above, and think how it would look with GOTOs all over the place.
> Avoid GOTOs!

> for(...) {
> if (PyErr_Occurred()) break;
> }
> if (PyErr_Occurred()) break;

I'm not sure I'd agree that breaking out of a loop just to test the same error condition,
to then only break out of another loop is any clearer than just jumping out directly.

Like someone mentioned, some other programming languages have dedicated constructs
(like exceptions) that can break out of multiple loops. It's not very different from what goto
was recommended for in this case.

(The thing with absolute rules is, that they absolutely forbid one from thinking. That usually
doesn't lead to anything good, so I would advise against it.)

> Fine. Try reworking the example I gave above, then. That has allocations nested up to three levels
> deep, as well as loops. See how well that works using GOTOs.

Reducing the nesting level and using a less space-hungry indenting style would be what I'd start with,
if I were to do this exercise for you.

Re: not sure I'd agree that breaking out of a loop just to test the same error condition

Posted Dec 27, 2014 20:46 UTC (Sat) by ldo (guest, #40946) [Link] (7 responses)

If you look at my code, you will see that each nested level has to do its own cleanup before propagating the error condition onwards. That is the whole point of the nesting.

Re: not sure I'd agree that breaking out of a loop just to test the same error condition

Posted Dec 27, 2014 20:57 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

Really? What cleanup is performed here: https://github.com/ldo/dvd_menu_animator/blob/master/spuh... ?

Or here: https://github.com/ldo/dvd_menu_animator/blob/master/spuh... ?

I actually don't see complicated cleanups anywhere in your code.

Re: What cleanup is performed here:

Posted Dec 27, 2014 21:36 UTC (Sat) by ldo (guest, #40946) [Link]

Try here or here.

Re: not sure I'd agree that breaking out of a loop just to test the same error condition

Posted Dec 28, 2014 3:27 UTC (Sun) by reubenhwk (guest, #75803) [Link] (4 responses)

>> If you look at my code, you will see that each nested level has to do its own cleanup before
>> propagating the error condition onwards. That is the whole point of the nesting.

Better yet, use a function for each of those nested levels. Worried about spaghetti code? Then factor out the nesting and call smaller functions with less looping and less nested resource management. Use the return value to propagate error conditions onward.

Re: Better yet, use a function for each of those nested levels.

Posted Dec 28, 2014 6:34 UTC (Sun) by ldo (guest, #40946) [Link] (3 responses)

Fine. Rewrite some suitably representative part of my code to show us an example of what you mean. There seems to be an enormous reluctance among you so-called programmers to actually do this. Perhaps because every time you try it, you get it wrong.

Re: Better yet, use a function for each of those nested levels.

Posted Dec 29, 2014 2:58 UTC (Mon) by reubenhwk (guest, #75803) [Link]

Perhaps we're on vacation and, even if we weren't, we have better things to do..

Re: Better yet, use a function for each of those nested levels.

Posted Dec 29, 2014 3:19 UTC (Mon) by bronson (subscriber, #4806) [Link] (1 responses)

Interesting use of the word "us". The royal we?

Re: Better yet, use a function for each of those nested levels.

Posted Dec 29, 2014 17:30 UTC (Mon) by nix (subscriber, #2304) [Link]

Probably the millions of lurkers who support him in email, using his fabulously readable coding style. I know I've encountered it everywhere! (... wait, that should be "nowhere".)

The argument from popularity is not a good one, but if something is not popular it is not terribly wise to imply that in fact it is.

Re: There would be precisely as many "goto" statements

Posted May 23, 2017 13:09 UTC (Tue) by mirabilos (subscriber, #84359) [Link]

It’d even be _easier_ in the case of nested loops, as something like shell’s “break 2” does not exist in C. A sole goto, to the shared exit path.

Avoiding GOTO at all cost is overreacting. The “rule” is probably good to teach to novice programmers, but experts are beyond it. Error handling is *the* prime example in favour of GOTO, although I agree there may be others.


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds