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-20 14:15:39 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!skynet.be!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: Wed, 20 Jun 2001 16:57:52 -0400 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: <9gr2og$gpj$1@nh.pace.co.uk> References: NNTP-Posting-Host: 136.170.200.133 X-Trace: nh.pace.co.uk 993070672 17203 136.170.200.133 (20 Jun 2001 20:57:52 GMT) X-Complaints-To: newsmaster@pace.co.uk NNTP-Posting-Date: 20 Jun 2001 20:57:52 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:8941 Date: 2001-06-20T20:57:52+00:00 List-Id: Consider the following: if (Some_Boolean_Function (X) and then Another_Boolean_Function (Y)) then Do_Some_Stuff ; end if ; If the *first* function almost always evaluates to False, then you almost never call the second function. This is efficient - a good thing sometimes. However, if the second function sometimes generates a Constraint_Error because of a programmer mistake, and it only sometimes gets called, you may have an error condition that makes it out into the field - which is A Bad Thing (tm). Another consideration is timing. Nominally, you only call the first function and not the second. In some corner cases, you call the second and this may consume some excessive amount of time. It may blow the timing budget altogether. Lots of hard realtime systems insist that you always execute the worst-case path just to make sure this sort of thing doesn't happen. This is the same reason why lots of realtime systems don't like cache on a chip - it leads to non-deterministic behavior that you may not find until it is too late. 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. 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/ "Beard, Frank" wrote in message news:mailman.993066684.13202.comp.lang.ada@ada.eu.org... > I've heard this before, as well. And it makes sense, unless there is > some problem or inefficiency with generating the underlying branch > statements. > > It seems to me that the "and" and "or" should have been implemented > in the short circuit form to begin with, instead of requiring > "and then" and "or else". As soon as one of the conditions is FALSE > for "and" or TRUE for "or", there is no need to check the remaining > arguments.