On Saturday, December 30, 2017 at 8:35:27 AM UTC+5:30, Lawrence D’Oliveiro wrote: > On Saturday, December 30, 2017 at 12:12:23 PM UTC+13, bartc wrote: > > Looking at 14 million lines of Linux kernel sources, which are in C, > > over 100,000 of them use 'goto'. About one every 120 lines. > > That kind of thing leads to spaghetti code. > > Here <https://github.com/ldo/dvd_menu_animator> is an example I like to bring > up: writing a Python extension module in C. As you know, this requires a lot > of careful memory management to cope with errors and avoid either memory > leaks or double-frees. The coding convention I came up with looks like this: > > ... initialize pointers to allocated storage to NULL ... > do /*once*/ > { > ... processing ... > allocate some storage; > if (error) > break; > ... more processing ... > allocate more storage; > if (error) > break; > ... even more processing ... > } > while (false); > ... free allocated storage ... > > Basically, it becomes possible to satisfy yourself, by inspection, that every > possible control path through the above code will pass once, and only once, > through the storage deallocation. > > Things get slightly more complicated where allocation has to happen in a > loop. Actually, that’s where the interesting cases happen. My technique can > be adapted to cope elegantly with this, too--see the code.
Bizarre how religions proliferate… I wonder how many people who quote Dijkstra have read "goto statement considered harmful". And that short letter was negative, aka "Don’t use goto!” The more positive answer to the question: “Ok so then how to program?” was "Structured Programming" I am ready to bet that an even tinier percentage has ever seen that tome And if one really got the gist of structuredness: mapping an automaton with state = label transition = goto is really the most clean structured mapping One can do almost as well with a switch and (case) labels You can make a virtue of the fact that python has neither I call it blind religious genuflecting BTW there can be quite good reasons for not putting¹ goto into a language especially interpreted ones is that gotos tend to make semantics non compositional: ie Say S₁ S₂ are two statements in the source language composed together into a larger source statement S₁ □ S₂ which translates into T₁ ▽ T₂ Egs of S₁ □ S₂ could be ifthenelse sequencing etc T₁ ▽ T₂ could be assembly code for S₁ followed by code for S₂ (for a compiler) Or action of S₁ followed by action of S₂ (for interpreter) Now if S₁ , S₂ has gotos jumping into each other this "homomorphic tree transforming model" becomes messed up However in the face of exceptions² that are quite close to gotos I dont think this logic would apply Finally I would like to quote my teacher of programming who made a statement that altered my next 30 years of programming life: “What the goto does to control structure, the assignment does to data structure” ¹ The most important decisions for a language designer are what to leave out — Nicklaus Wirth ² The original objectives of the language (Ada) included reliability, readability of programs, formality of language definition, and even simplicity. Gradually these objectives have been sacrificed in favor of power, supposedly achieved by a plethora of features and notational conventions, many of them unnecessary and some of them, like exception handling, even dangerous C.A.R. Hoare Turing lecture: https://amturing.acm.org/award_winners/hoare_4622167.cfm -- https://mail.python.org/mailman/listinfo/python-list
