peter@neccan.oz (Peter Miller) (04/30/90)
in article <2647@mica6.UUCP>, henley@motcid.UUCP (Aaron Henley) says: > I always thought a BREAK statement was equivalent to a GOTO > statement but the compiler sets up the labels. For those > who don't like the use of GOTO in their code you shouldn't > like the BREAK either. Try looking at your assembly output! > I did a diff on the .i files using a break compared to a goto and the > only difference was the label name. Oh, come on! I could paraphrase it as "I always thought an IF statement was equivalent to a GOTO statement but the compiler sets up the labels. For those who don't like the use of GOTO in their code you shouldn't like the IF either. Try looking at your assembly output!" You are forgetting that structured programming is a TOOL. Too many treat it as dogma. And we all hate bigots. GOTOs are essential to algorithms. Just because you choose to use a language construct which hides them does not alter the fact that they are there. The only question I ever ask about a goto is "Is it more maintainable/understanable/readable to use a goto or not to use a goto?" I try to avoid the dogma. Regards Peter Miller UUCP {uunet,mcvax,ukc}!munnari!neccan.oz!pmiller ARPA pmiller%neccan.oz@uunet.uu.net /\/\* CSNET pmiller%neccan.oz@australia ACSnet pmiller@neccan.oz Disclaimer? These guys have no idea what I am on about! D
chris@mimsy.umd.edu (Chris Torek) (05/02/90)
In article <1990May1.165701.4289@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >Why use loops, or ifs, or any other control structures, which replace some >subset of the functionality of the goto? Because they are easier to read >and harder to make mistakes with. ... The constraint [that break and >continue impose on code reachability] is important, indeed crucial; >without it, one might as well use goto. This is the heart of the matter. Like power tools, powerful constructs should always be avaliable; like power tools, powerful constructs should not be the workman's only choice. One does not use a table saw to cut a small notch in a small piece of wood. In its rawest form (which, in C, is actually represented as longjmp, not as the keyword `goto'), `goto' is the most powerful control construct that exists. *All* other control constructs, including `return', are simply restricted forms of `go to'. The restrictions exist precisely because the result is easier for programmers (and, to a limited extent, for compilers) to handle. If you intend for your code to be readable and maintainable, you should find the least powerful constructs that solve the problems you need solved in the most straightforward manner available. (This leaves a great deal of room for dispute as to what is straightforward. This is as it should be. It also says nothing about external constraints, efficiency and expediency being primary examples. This, too, is as it should be---general principles have to be simple and neat, and ignore the Real World.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris
henley@motcid.UUCP (Aaron Henley) (05/03/90)
henry@utzoo.uucp (Henry Spencer) writes: >Why use loops, or ifs, or any other control structures, which replace some >subset of the functionality of the goto? Because they are easier to read >and harder to make mistakes with. The proposal wasn't to make break the >same as goto, but to provide a way of using break to exit multiple levels >of loops. Since humans find counting levels difficult, one should tag the >levels with names rather than requiring a count. Nobody has suggested the >equivalent of "#define break goto"; break would still be constrained to use >only for exiting loops (well, and switches). The constraint is important, >indeed crucial; without it, one might as well use goto. Noted, I misinterpreted this discussion, sorry. Does break <label> statement mean that the continue should also have a label? >>... I do recommend people out there to >>experiment with your code and look into your assembly listings if your >>not sure of the best way to code a particular piece of code or if you >>want to *REALLY* understand what your C code is doing! >With a good optimizing compiler, you could spend all day just trying to >figure out the relationship between what you wrote and what the compiler >produced. Not, generally, an enlightening exercise. Also a fruitful source >of misunderstandings, given the frequency of obscure compiler bugs. To >really understand C, you should study C, not assembler. I have to disagree with this point. I think people should and in many cases must be aware of how their compiler allocates memory for structures, what happens when you typecast a word from a memory location starting at a point that isn't word aligned, etc... These and many other usages of C are ambiguously defined. Just as there are a large frequency of obscure compiler bugs, there are several ways different compilers handle ambiguous situations, many of which cannot be found in the compiler's documentation. My intent was not to suggest that you create a C program and then study the assembly listing, but inorder to write efficient C code that does what you want, you may have to consider what your compiler is generating. So test the code in question in a small test program and see what the assembly code looks like, neither of which should be time consuming. If your interest is very specific you should have little or no trouble tracking down the functionality of the code in question. Aaron -- ___________________________________________________________________ / Aaron Henley, Motorola Inc. DISCLAIMER: std.disclaimer / / Cellular Infrastructure Division UUCP: ...!uunet!motcid!henley / /__________________________________________________________________/
henry@utzoo.uucp (Henry Spencer) (05/03/90)
In article <2713@mica6.UUCP> motcid!henley@uunet.uu.net writes: >>All control structures are gotos in disguise. The point is that more >>constrained structures are easier for human beings to understand... > >Why don't you program in PASCAL if you want something simple and easy >to read... Mostly because I don't believe one must abandon simplicity and readability in order to get a usable programming language. Despite its flaws, C works pretty well if you avoid the worst rough spots. >Also 99% of the code I review and 100% of the code I have supported >was available online. If I had a problem finding a label, grep always seemed >to work... I've programmed using punchcards, and they work, but I feel no desire to return to them. The ease of finding labels is irrelevant; one should not have to perform that particular chore at all. Not doing something is almost always less work than doing it, even with the best tools. Writing code that requires your successor to use grep to understand it is improper and unprofessional. >Incidentally, having written and inspected serveral K lines of code, >I've never seen a case where a loop was used in this way and shouldn't have >been made into a subfunction(since it provided its own functionality). Actually, I am inclined to agree. The original proposal strikes me as elaborating on the wrong solution. However, it should be cricitized on those grounds, not on the grounds that it is somehow equivalent to goto, which it isn't in any meaningful sense. -- If OSI is the answer, what is | Henry Spencer at U of Toronto Zoology the question?? -Rolf Nordhagen| uunet!attcan!utzoo!henry henry@zoo.toronto.edu