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…
GOTOphobia considered harmful in C
221–230 of 319 posts
Re: GOTOphobia considered harmful in C
#222Earlier 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.
Re: GOTOphobia considered harmful in C
#223I 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…
Just like 8 bit BASIC spaghetti code, only refined.
Re: GOTOphobia considered harmful in C
#224Earlier 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.
> 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
#225This 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.
Re: GOTOphobia considered harmful in C
#226Earlier 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.
Re: GOTOphobia considered harmful in C
#227Earlier 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…
Re: GOTOphobia considered harmful in C
#228I 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…
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
#229Earlier 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, 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
#230This 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…
They seem to generate a lot of hate though.