On Wednesday, June 15, 2016 at 9:24:21 PM UTC+5:30, Random832 wrote: > On Wed, Jun 15, 2016, at 10:20, Rustom Mody wrote: > > Claim is that the damaging propensities of goto are replicable with > > break. > > The "damaging propensity" in this particular case simply comes from the > fact that it's a statement that can appear in the body of an if > statement (the real flaw that caused the bug here here was the optional > braces of the if statement), which is just as true of anything else. It > could have called a function that it shouldn't have called.
People have adduced various reasons: 1. Optionality of braces 2. gcc silently non-mentioning dead code 3. indentation and braces mismatch -- were it python(ish) the second goto would be harmless dead code INSIDE the if 4. Careless merging 5. Culture of cut-paste 6. All kinds of soft questions -- code should be reviewed/pair-programmed/etc 7. Even more irrelevant soft point -- Apple is a bad company for being thus irresponsible 8. etc > > But a lot of people do claim that break should be generally "considered > harmful" just like goto and never used at all because of this > isomorphism. Minor point: I dont think isomorphism is correct As I said the goto can originate anywhere and target to anywhere (in function scope). Not break longjmp can scale function scopes but has other restrictions like respecting the stack, the setjmp-site needs to have been visited first. IOW different unstructured constructs have differing properties Major point: "Considered harmful" should be considered harmful :-) IOW cargo-cult programming without any understanding is worse than specific fads There are things -- eg automata -- where the most faithful rendering is with gotos: : labels for states, gotos for transitions. Any 'more structured' solution is usually more messy. OTOH Duff's device shows terrifyingly unstructured code with nary a goto/break in sight So break also has its uses. Lets just not pretend its structured -- https://mail.python.org/mailman/listinfo/python-list
