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-7-bit X-Google-Thread: 103376,db5c6b2ef47d4b9e X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-06-21 10:20:12 PST Path: archiver1.google.com!news2.google.com!newsfeed.google.com!sn-xit-03!sn-xit-02!supernews.com!newsfeed.direct.ca!look.ca!news1.tor.metronet.ca!nnrp1.tor.metronet.ca!not-for-mail Message-ID: <3B322AC5.2B8DC7B1@home.com> From: "Warren W. Gay VE3WWG" X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: short-circuit control forms References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 21 Jun 2001 17:11:36 GMT NNTP-Posting-Host: 198.96.47.195 NNTP-Posting-Date: Thu, 21 Jun 2001 11:11:36 MDT Organization: MetroNet Communications Group Inc. Xref: archiver1.google.com comp.lang.ada:8989 Date: 2001-06-21T17:11:36+00:00 List-Id: "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