Re: short-circuit control forms

["Marin David Condic" <marin.condic.auntie.spam@pacemicro.com>]

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" <beardf@spawar.navy.mil> 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.