The Evolution of C Programming Practices: A Study of Unix (2016) [pdf]

Re:The Evolution of C Programming Practices: A Study of Unix... by masklinn on Friday May 11, 2018 @08:27AM (#17046757)

> People who think "goto" is evil should also give up the other jump statements: continue, break, and return (and also switch, though its not listed as a jump instruction in the C standard, at least not in '89 or '99).

That makes no sense. goto is maligned because it's unstructured, the other constructs you list are structured and restricted. Much like loops, conditionals and function calls they're specific and "tamed".

Not only that, but the historical movement against goto happened in a context were goto was not just unstructured but unrestricted (to local functions).

Even K&R warns that goto is "infinitely abusable", and recommends against it when possible (aka outside of error handling & breaking from multiple loops as C does not have multi-level break).

[ Parent | on HN ]

Re:The Evolution of C Programming Practices: A Study of Unix... by zzzcpan on Friday May 11, 2018 @08:45AM (#17046885)

Unstructured and unrestricted equivalent of goto then is a method call in OOP. Where method is basically a label and object is a shared state it randomly messes with.

[ Parent | on HN ]

Re:The Evolution of C Programming Practices: A Study of Unix... by coldtea on Friday May 11, 2018 @10:48AM (#17047658)

That's not unrestricted though -- control returns to the caller after the end of the function.

With goto that's not guaranteed to be the case -- that was the spaghetti part.

[ Parent | on HN ]

Re:The Evolution of C Programming Practices: A Study of Unix... by zzzcpan on Friday May 11, 2018 @06:22PM (#17051148)

No, that's not a restriction, but just a behavior. It doesn't keep you from jumping all over the place and modifying shared state by calling methods within methods. You can only use conventions to have some restrictions and structure here. Just like with goto.

[ Parent | on HN ]

Re:The Evolution of C Programming Practices: A Study of Unix... by goalieca on Friday May 11, 2018 @08:59AM (#17046949)

if (False) goto error;

vs.

if (False) throw ExceptionE;

[ Parent | on HN ]

Re:The Evolution of C Programming Practices: A Study of Unix... by Gibbon1 on Friday May 11, 2018 @12:10PM (#17048483)

Ehem

   if(False) longjump(error, 1);

   vs

   if (False) throw ExceptionE;

[ Parent | on HN ]

Re:The Evolution of C Programming Practices: A Study of Unix... by hindsightRegret on Friday May 11, 2018 @05:52PM (#17051027)

Good job, compiler :)

[ Parent | on HN ]

Re:The Evolution of C Programming Practices: A Study of Unix... by jimmy1 on Friday May 11, 2018 @11:59AM (#17048352)

You highlighted in this comparison why I hate exception handling in OOP languages, and just generally the common practices prescribed for handling errors.

[ Parent | on HN ]

Re:The Evolution of C Programming Practices: A Study of Unix... by kazinator on Friday May 11, 2018 @08:07PM (#17051625)

switch is unstructured to a large degree:

  switch (val)
    while (cond)
    {
      case 42: /* wee: if val is 42, we go straight here */
        break; /* this belongs to the while! */
    }

I have written this kind of jig the past:

   if (...) {

   } else switch (val) for(;;) {

   }

[ Parent | on HN ]