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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII X-Google-Thread: 103376,db5c6b2ef47d4b9e X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-06-22 09:34:33 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!paloalto-snf1.gtei.net!crtntx1-snh1.gtei.net!cambridge1-snf1.gtei.net!news.gtei.net!bos-service1.ext.raytheon.com!bos-service2.ext.raytheon.com.POSTED!not-for-mail Message-ID: <3B336844.9B58ED9A@ftw.rsc.raytheon.com> From: Wes Groleau X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en,es,fr,pt MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: short-circuit control forms (& 'long names are doom') References: <3B30F836.D700DAA3@raytheon.com> <3B32038D.F1296C79@cadence.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Fri, 22 Jun 2001 10:46:12 -0500 NNTP-Posting-Host: 151.168.144.162 X-Complaints-To: news@ext.ray.com X-Trace: bos-service2.ext.raytheon.com 993224775 151.168.144.162 (Fri, 22 Jun 2001 11:46:15 EDT) NNTP-Posting-Date: Fri, 22 Jun 2001 11:46:15 EDT Organization: Raytheon Company Xref: archiver1.google.com comp.lang.ada:9034 Date: 2001-06-22T10:46:12-05:00 List-Id: > There was an interesting thread on this subject back in 95 (search for short > circuit in the Google archives of comp.lang.ada). Didn't work. Seeral search methods only returned parts of this (current) thread. > I found Tucker Taft's comment particularly interesting: > > ": If both operands are > : always evaluated, does that mean that whenever it is unnecessary to > : evaluate the second operand, one should use the short-circuit operators > : for efficiency? I hope he's listening, because without seeing the whole post, I strongly suspect that his answer was "no" > To avoid depending on the quality of your compiler's optimizer, > I personally recommend using short-circuit operations by default, > and only use "and" or "or" when it is *required* that both > operands be evaluated. I do not recommend "depending on" the optimizer, but I recommend even more strongly NOT disabling the optimizer. > Hence, if your compiler is clever, it doesn't matter what you > do since it will un-do it if appropriate, and if your compiler is If _allowed_ and appropriate. > not clever, then using short-circuit by default probably produces > somewhat better code quality on average. For reasons already stated in this thread, I doubt it. That's if you define "code quality" as "efficient." If you define it as clear, readable, and less error-prone, then for reasons already stated in this thread, I doubt it. What surprises me the most about our "profession" in general is the fact that the folks "in the trenches" habitually ignore the good advice of the "experts" that we claim to respect. Since nearly THIRTY YEARS AGO (and probably longer), folks have known and written of the foolishness of misguided "optimization" efforts (emphasis mine): Kernighan & Plauger, 1974. Elements of Programming Style: Make it right _before_ you make it faster. _Keep_it_right_ when you make it faster. Make it clear _before_ you make it faster. Don't sacrifice _clarity_ for small gains in "efficiency." Let your _compiler_ do the simple optimizations. Keep it _simple_ to make it faster. [I have fixed at least as many bugs by _removing_ code as I have by adding code. -WWG] Don't diddle code to make it faster � find a better algorithm. Instrument your programs. _Measure_ before making "efficiency" changes. Ledgard, Nagin, Hueras, 1979. Pascal with Style: Programming Proverbs: Shortening the code, running the program faster, or using fewer variables are all popular pastimes. ..... Not mentioning ... the extra testing time needed to check the new and often subtle boundary conditions, are you _sure_ that fewer machine instructions or faster machine execution is likely? Some others which I have not been able to verify the sources of: Rules of Optimization: Rule 1: Don't do it. Rule 2 (for experts only): Don't do it yet. - M.A. Jackson "More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason - including blind stupidity." - W.A. Wulf "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." - Donald Knuth -- Wes Groleau http://freepages.rootsweb.com/~wgroleau