Live data from Hacker News

GOTOphobia considered harmful in C

blog.joren.ga

221–230 of 319 posts

Re: GOTOphobia considered harmful in C

#221
post #140

Earlier quoted context omitted.

To give people some kind of an idea of what it was created in response to: Imagine writing an entire program in one single main function. The only thing you're allowed to do for flow control is goto. You can do 'goto somelabel;' for an unconditional goto, or you can do 'if (somecondition) goto somelabel;' for a conditional goto. Here's some examples of how it would look if if translated to something C-like: Loops wou…

tangentially, can somebody point me to what are considered the best fizzbuzz solutions? I'm both an experienced and cs-educated coder, and I know what I would consider to be a good solution, but I have no idea what the rest of "you" are looking for. (my favored solution would be a small number of state machines running in parallel to sieve-of-eratosthenes the correct answers thus avoid innumerable divisions, but mayb…

I don't claim to have the best, or even good, fizzbuzz implementations, but if you're looking for a lot of fizzbuzz implementations:

https://github.com/Keith-S-Thompson/fizzbuzz-c

https://github.com/Keith-S-Thompson/fizzbuzz-polyglot

Re: GOTOphobia considered harmful in C

#222

Earlier quoted context omitted.

You can totally throw an exception from RAII code if you declare the destructor noexcept(false). Goto + RAII isn’t generally compatible unless you structure things very carefully

You can, and your program will call std::terminate if there’s already an exception being processed. Not exactly desirable if you’re trying to write code that ensures careful resource cleanup. Also why it’s widely regarded as _wrong_ to ever throw in a destructor.

Program termination is _the_ _perfect_ resource cleanup (at least when running on a decent OS.)

Re: GOTOphobia considered harmful in C

#223
post #77
post #50

I always encourage people to go read Dijkstra's GOTO paper, instead of just its title. It's a short and easy read, almost like a blog post. If you pay attention, you can see that the he was talking about spaghetti code vs structured code. It's better when the lexical structure of the source code maps to the execution structure. That is, if you know what is the current line being executed, you have a good idea of what…

The thing is that many people today have never encountered the sort of spaghetti code that Dijkstra was talking about in 1968. There's plenty of confusing and messy code around, but true spaghetti code that GOTOs all over the place and is nigh-impossible to follow has been extremely rare for a long time. I can't recall encountering it in the last 30 years. It easy to misunderstand what he was even talking about becau…

I kind of have, instead of GOTOs, we have RPC calls on the flavour of the day, that just GOTOs only make sense after doing a full diagram of call sequences.

Just like 8 bit BASIC spaghetti code, only refined.

Re: GOTOphobia considered harmful in C

#224

Earlier quoted context omitted.

Returns are also gotos then.

Not in the Dijkstra "Go to statement considered harmful" sense. Nor are the goto keywords found in most modern languages. These retain structure and thus are not considered harmful. But there is a good case to be made that exception handlers are gotos in the Dijkstra sense, at least when used for anything other than exceptions, like passing errors around.

If you read Dijkstras letter it is clear that early returns (ie any return which is not the last statement in a function) is subject to the same criticism as goto.

> These retain structure and this are not considered harmful

This might be your opinion, and it is a very reasonable opionin. But it is just not what Dijkstra is arguing. He is very clearly arguing for “single entry single exit”.

Re: GOTOphobia considered harmful in C

#225
post #39

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…

Only some goto use cases.

Did I say otherwise? D still has a goto, though it is rarely used anymore.

Re: GOTOphobia considered harmful in C

#226
post #192

Earlier quoted context omitted.

If you're steeped in C and its quirks, have good coding patterns that allow for it, I say knock yourself out. I'm absolutely coding in C again — writing some old-school games using SDL. After working for decades with various retain/release, garbage-collected, magic-memory™ languages, going back to C feels like programming again. I like it.

> If you're steeped in C and its quirks, have good coding patterns that allow for it, I say knock yourself out. Somewhere between 95% and 100% of people who think they're "steeped in C and its quirks, have good coding patterns that allow for it" write code that invokes undefined behaviour.

There's nothing wrong with undefined behaviour.

Re: GOTOphobia considered harmful in C

#227
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…

If you have ever seen someone try an construct a bunch of nested IF statements with complicated conditional clauses you might think GOTO is not so bad. People have simply become better coders. There are also still GOTOs that are used in specific cases such as CONTINUE and BREAK - no labels required. If I look back it always comes back to naming and managing names of things. GOTO 100 is meaningless and one eventually…

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.

Re: GOTOphobia considered harmful in C

#228
post #50

I always encourage people to go read Dijkstra's GOTO paper, instead of just its title. It's a short and easy read, almost like a blog post. If you pay attention, you can see that the he was talking about spaghetti code vs structured code. It's better when the lexical structure of the source code maps to the execution structure. That is, if you know what is the current line being executed, you have a good idea of what…

Interestingly, many seem to want to project their own opinion upon Dijkstra.

Dijkstra is clearly arguing for a “single entry single exit” style. But modern consensus seem to uphold single entry but accept multiple exits from a block. Break, continue, early returns, exceptions - all are example of multiple exit. These are more constrained than gotos but nevertheless Dijkstras argument applies to them also.

I personally belive early returns can greatly improve readability (when not nested too deep) an that exceptions are typically cleaner than the alternative. But I acknowlede Dijkstra would disagree.

Re: GOTOphobia considered harmful in C

#229

Earlier quoted context omitted.

If you have ever seen someone try an construct a bunch of nested IF statements with complicated conditional clauses you might think GOTO is not so bad. People have simply become better coders. There are also still GOTOs that are used in specific cases such as CONTINUE and BREAK - no labels required. If I look back it always comes back to naming and managing names of things. GOTO 100 is meaningless and one eventually…

CONTINUE and BREAK are quite different from GOTO in that they operate predictably given the current scope: their limitations make them incapable of creating the unstructured nightmare that Dijkstra was talking about. They're similar to a GOTO only in that they compile to a jump, but so do IF statements and FOR loops. Structured programming wasn't about eliminating jumps, it was about enforcing discipline in their use…

> CONTINUE and BREAK are quite different from GOTO in that they operate predictably given the current scope

CONTINUE, BREAK, and GOTO all operate predictably because they are deterministic operations. Each continues program execution at the directed explicit (goto) or implicit (continue or break) offset. There is no non-deterministic or unpredictable behavior whatsoever.

Re: GOTOphobia considered harmful in C

#230

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.

Post reply on HN