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=-0.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00 autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,db5c6b2ef47d4b9e X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-06-21 11:05:23 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news.tele.dk!194.8.194.95!news.netcologne.de!fr.clara.net!heighliner.fr.clara.net!newsfeed.planete.net!psinet-france!psiuk-f4!psiuk-p4!uknet!psiuk-n!news.pace.co.uk!nh.pace.co.uk!not-for-mail From: "Marin David Condic" Newsgroups: comp.lang.ada Subject: Re: short-circuit control forms Date: Thu, 21 Jun 2001 13:49:26 -0400 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: <9gtc36$cab$1@nh.pace.co.uk> References: <3B322AC5.2B8DC7B1@home.com> NNTP-Posting-Host: 136.170.200.133 X-Trace: nh.pace.co.uk 993145766 12619 136.170.200.133 (21 Jun 2001 17:49:26 GMT) X-Complaints-To: newsmaster@pace.co.uk NNTP-Posting-Date: 21 Jun 2001 17:49:26 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Xref: archiver1.google.com comp.lang.ada:8993 Date: 2001-06-21T17:49:26+00:00 List-Id: Thanks for the support. You pretty well summed it up. *If* the timing is critical enough to be concerned about the efficiency of short-circuit vs regular forms, then you *probably* want to make sure you always execute the worst case scenario because you have not got the CPU to spare if it doesn't work in the worst case. In my mind, the only situation where this sort of really low level optimization matters is the situation where you wouldn't want to be doing this anyway. If you can afford the worst case, what does it gain you to do the best case? Can you put those handful of spare CPU cycles to work somewhere else on an "as available" task? The context switch would likely eat more than what you saved. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Warren W. Gay VE3WWG" wrote in message news:3B322AC5.2B8DC7B1@home.com... > "Beard, Frank" wrote: > > -----Original Message----- > > From: Marin David Condic [mailto:marin.condic.auntie.spam@pacemicro.com] > > > > > Better to have the short-circuit things optional so you can manually > > enable > > > and disable the behavior as needed. Most of the time the extra efficiency > > is > > > likely to be a) too small to sweat and b) not an issue because it isn't a > > > hard realtime system. > > > > Well, the argument could be made that if your second condition raised an > > exception then your unit testing was insufficient (and yes I know unit > > tests can't always catch everything). > > But Marin's point was that if you want to be closer to 100% sure that > this piece of code will not raise an exception or blow the CPU budget, > then you need to make sure that it is _always_ executed. Otherwise, you > have to create the right kind of conditions to test that 0.01% -- which, > might be near impossible without modifying the code (which itself > invalidates the test). If I were flying on that code, then I'd want > the AND to be used, and not the AND THEN clause. The object is to have > greater confidence in the testing. > > > And as a general rule, it's a bad > > idea to write functions with side effects, unless you have some glaring > > necessity to do so. > > Nobody disagrees with this, but even functions without side-effects > can create exceptions. That was the point. Also, it is possible for > functions to have different CPU budgets, depending upon the inputs. > This should be tested thoroughly. > > > Most, if not all, of the conditional statements that > > I've written fall into the "and then" and "or else" category. > > I could see this in a non-critical piece of software. But where > rigorous testing is involved, you will simplify your life by using > the naked AND instead (where possible at least). > > > But as a point Marin has already made, I don't even worry about any of > > these cases unless there is some runtime penalty. In most cases, I > > just use "and" and "or" because the code is cleaner looking. > > Coming from a C/C++ background, I tend to err on the side of > short circuiting, but realize that this is not always wise. Even if > you spend most of your life in business like, non-critical systems, > you could end up writing re-usable code that may be applied differently > than you imagined, by someone else. > > For this reason, you _should_ probably assume the worst case, as > suggested by Marin, so that you don't inflict trouble on the next > user of your code. The other benefit, as been pointed out, it is > easier to test your code and gain greater confidence from your > tests (greater path coverage). > > -- > Warren W. Gay VE3WWG > http://members.home.net/ve3wwg