From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,99222a5bd46ef3c9 X-Google-Attributes: gid103376,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: GOTO considered necessary (reworked) Date: 1997/06/17 Message-ID: #1/1 X-Deja-AN: 249028476 References: <5nn2fm$11dk$1@prime.imagin.net> <5nonfk$rcr@top.mitre.org> Organization: New York University Newsgroups: comp.lang.ada Date: 1997-06-17T00:00:00+00:00 List-Id: Michael Brenner says <> I agree that few (but not no) compilers will be able to convert the canonical case/state formulation to the formulation with jumps, so it is certainly reasonable to cite the efficiency argument. Still I think the cases in which one should let efficiency dominate stylistic considerations are very rare. To do this other than in cases where you really KNOW that the efficiency is that critical seems to be to be premature optimization. In addition, the general approach of trying to outguess an optimizing compiler often leads people to do quite counterproductive things. Within broad boundaries, I think the best approach is to write in the clearest way possible, and then, if there is an efficiency problem, examine ways to improve the code. I say within broad boundaries, because one needs to have a reasonable feel for gross levels of efficiency. For example, I sometimes see Ada 95 programs where controlled types have been used with complete abandon and obvious obliviousness to the fundamental inefficiencies that result. But I would seldom chose between ways of doing things on an efficiency basis, and I certainly would not do so in this case. I would use the goto approach because I think it is clearer, even if it was less efficient, unless I found that it made a critical efficiency difference. Obviously if you do not share the quite common view that the goto representation of FSM's (i.e. encoding the state in the code location) is clearer, then you will think that efficiency is the concern, but to elevate efficiency as the primary motive in this document would be quite misleading, since it would miss the point that the FSM case is one of those rare cases where a significant number of people *do* consider that the goto representation is clearer.