Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GOTOphobia considered harmful in C

blog.joren.ga

Post reply on HN
Print view View original

301–310 of 319 posts

Re: GOTOphobia considered harmful in C

#301

Post by lolinder »

bdowling wrote: post #298
lolinder wrote: post #297

Earlier quoted context omitted.

No, you're still mixing up the subtype relationship. Type X is a subtype of type Y if and only if an instance of X can always be used where an instance of Y is required. GOTO can always be used to replace a BREAK. Therefore GOTO is a subtype of BREAK. BREAK cannot always be used to replace a GOTO. Therefore BREAK is not a subtype of GOTO. The inheritance relationship here is not single, it's multiple: a GOTO is a BRE…

We apparently disagree on whether the general, flexible construct is the subtype or whether the specific, constrained construct is the subtype. You seem to be thinking from a object-oriented programming class hierarchy perspective, while I am thinking from a set theory perspective (i.e, the set of operations that can be done with GOTO is a superset of those that can be done with CONTINUE or BREAK). At this point, I d…

I actually rather enjoyed the conversation and didn't feel it was wasted at all, but I'm sorry you didn't feel the same. I wasn't in it to win, just to explore the idea.

I'm still interested in exploring the idea, but you're welcome to tune out at any point.

> the set of operations that can be done with GOTO is a superset of those that can be done with CONTINUE or BREAK

Yes! And this is actually part of my point. If Y is a subtype of X, then the set of valid operations on Y is a superset of the set of valid operations on X. This is true for any types, by the definition of subtyping.

This means that you're absolutely correct that the set of operations GOTO can perform is a superset of those BREAK can perform, and for this very reason GOTO is a subtype of BREAK.

The reason why I'm focused on the types and not the operations is because the question at hand has been whether BREAK has the same flaws as GOTO. My argument is that this hinges on whether or not BREAK is just a type of GOTO.

Re: GOTOphobia considered harmful in C

#302

Post by l33t233372 »

kazinator wrote: post #246
l33t233372 wrote: post #232

Earlier quoted context omitted.

> the idea that for loops are somehow easier than recursion is definitely not from mainstream CS I have never in my life heard a programmer say they think recursion is easier than loops.

That only shows you haven't known any programmers who had a broad exposure to the topics of their supposed craft; it doesn't speak to the actual topic itself. Recursive solutions being easier to verify is quantifiable . This is not some popularity poll. Some people are not well-versed in some techniques. Recursion is not always well supported in programming languages. In standard C if we want to use recursion, we wil…

> Recursive solutions being easier to verify is quantifiabl

Ease of doing something is a quantifiable description?

Re: GOTOphobia considered harmful in C

#303

Post by nullc »

RustyRussell wrote: post #288
nullc wrote: post #227

Earlier quoted context omitted.

A better rule than goto harmful is gotos should only go lower in the function and should only exit blocks and/or skip over them, never be used to enter them.

Generally true, but I've been known to do `goto again;` for those cases where retrying is a corner case. Sure, you can put the entire code inside a `for(;;)` but if it almost always only runs once, you're not helping the reader understand the code.

I'm fond of the MISRA C approach where you have all these bright line (even machine checkable maxims) but if you have a reason to break one you're just supposed to write up a report why its better to do it this way and how you've addressed the risks.

Seems like a reasonable trade for the occasional "goto again".

[Before anyone reads the above as advocating MISRA C ---- I think MISRA actually tells you not to do "goto fail;" which is advice I'm kind of dubious about. It also tells you to not do "good = good && side_effecty_thing();" (no shortcutting operators when there are side effects) so its style has you make a typical function absolutely littered with explicit initialization guards.]

Re: GOTOphobia considered harmful in C

#304

Post by WalterBright »

Gibbon1 wrote: post #230
WalterBright wrote: post #35

This is fun! The C version; int foo(int v) { // ... int something = 0; switch (v) { case FIRST_CASE: something = 2; goto common1; case SECOND_CASE: something = 7; goto common1; case THIRD_CASE: something = 9; goto common1; common1: /* code common to FIRST, SECOND and THIRD cases */ break; case FOURTH_CASE: something = 10; goto common2; case FIFTH_CASE: something = 42; goto common2; common2: /* code common to FOURTH a…

gcc supports nested functions. I like them lots. They seem to generate a lot of hate though.

I've never used them, so have no opinion on that.

Re: GOTOphobia considered harmful in C

#305

Post by rocqua »

billforsternz wrote: post #141
spacedcowboy wrote: post #61

I'm browsing this, and I'm not seeing the way I do it, which is sort-of-like #5 but not quite... I tend to wrap the code that has multiple exits-to-label in a do...while(0) loop, and use break to get there... So it might look like: do { if (false == call_func1()) { cleanup_any_state(); break; } if (false == call_func2()) { cleanup_any_state(); break; } } while (0); At any point you can branch to the common exit-state…

I don't like the code pattern if ( false == func() ). Function func() already returns a boolean, no need to compare that to a second boolean (false or true) to generate a third boolean. Sorry, a little off topic I know.

In languages without type coercion, it helps add some type checking by ensuring you return a bool rather than some value that has truthity.

Re: GOTOphobia considered harmful in C

#306

Post by benj111 »

maldev wrote: post #290
benj111 wrote: post #110

Earlier quoted context omitted.

or maybe its that things like a kernel reasonably need to use goto? or at least at the time it was written, there werent alternatives that were performant enough.

I'm not saying not to use goto. The above example works on any C language, with some tweaks needed to K&R. I've done substantial Kernel work and can tell you that there's no reason to ever break my example and put multiple goto stubs. Can you provide a single situation where it is needed and there's no other alternative? I can't prove the negative you want me to.

I'm not convinced that "more than 1 goto location considered harmful" is any different from "goto considered harmful"

Each has its place. You don't 'need' to use Goto's at all. Your example could be achieved with more flags and if statements.

Re: GOTOphobia considered harmful in C

#307

Post by Closi »

bombolo wrote: post #164
Closi wrote: post #104

Earlier quoted context omitted.

Worth also noting the sort of wild limits with Basic too that are partially responsible for the code being spaghetti, including effectively an inability to add new lines in the code without adding a goto between previous statements.

What are you talking about? gwbasic had a function to relabel all the lines. And the labels skip by 10 numbers exactly for the purpose of inserting lines. Then when you had hit the limit you'd ask the computer to relabel them in steps of 10 again.

> gwbasic had a function to relabel all the lines. And the labels skip by 10 numbers exactly for the purpose of inserting lines. Then when you had hit the limit you'd ask the computer to relabel them in steps of 10 again.

gw-basic was released c4 years after this book, and there was a huge change over that period:

1976 - Release of Apple I

1977 - Release of Apple II / Commodore PET

1979 - This book

1982 - Commedore 64

1983 - GW Basic

This book is pretty much closer to the Apple I than gw-basic. Perhaps I should have specifically said developing basic in 1979 though as referenced in that book though (and there isn't just one sort of basic - there are so many dialects).

Re: GOTOphobia considered harmful in C

#308

Post by vasirian »

hegzploit wrote: post #244
jjav wrote: post #97

Earlier quoted context omitted.

> The thing is that many people today have never encountered the sort of spaghetti code that Dijkstra was talking about in 1968. Can't highlight this enough. The type of spaghetti code "goto considered harmful" was reacting to is basically impossible to create anymore, so anyone who didn't work on that type of code in the 80s or earlier probably hasn't seen it. And thus, is applying the mantra "goto considered harmfu…

Where would once find examples of such code?

Among others, likely in old introductory books on BASIC or its other flavors.

Re: GOTOphobia considered harmful in C

#309

Post by 0xfedbee »

pornel wrote: post #11

Manual goto cleanup is such a busywork, adding nothing of value, only places for potential leaks and UAFs. I know for C it’s unthinkable to standardize such a luxury like defer or destructors, so we’re going to relive arguments from 1968 for as long as C is used.

Sorry I’m still not going to use Rust

Re: GOTOphobia considered harmful in C

#310

Post by strangattractor »

bdowling wrote: post #294
lolinder wrote: post #277

Earlier quoted context omitted.

My point is that it's meaningless to make the argument that CONTINUE and BREAK can be implemented with GOTO, because every control flow structure can be . That you could use a GOTO to implement them isn't in question, what's in question is if you could do the reverse. It's a subtyping problem, and you have the is-a relationship backwards: a cat is an animal but not every animal is a cat. GOTO is a BREAK (could always…

> GOTO is a BREAK (could always be substituted for one), but a BREAK is not a GOTO. You wrote this backwards, but you seem to understand the relationship and that GOTO is more general. That is, every BREAK is a GOTO (because you can always substitute a GOTO), but every GOTO is not a BREAK (i.e., you can't substitute a BREAK for some GOTOs because BREAK cannot jump to an arbitrary label).

The moment I received a down vote for a simple opinion/observation about relieving naming overload and the similarities of BREAK and CONTINUE to GOTO I knew where this was going:)
Post reply on HN