Re: Short circuit boolean evaluation

["Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca>]

Gautier Write-only wrote:
> svaa:
>>I'm a newbie in Ada, I've worked in several languages, last three
>>years I've worked in Delphi (Pascal).
> 
> Welcome to professional programming...
> 
> Well. The efficiency of the "short circuit" is to be relativized,
> especially with the processors of the last 10 years where each
> condition (that automatically come with the short-circuit) means
> a serious slowdown. This "short circuit is faster"-mania is completely
> outdated. 

This is neither universally true, nor false. I know that the
discussion is centered around boolean tests here, but a
boolean test often includes a function call that returns
a boolean value. You cannot unversally state that by always
calling the boolean function, that it is going to be just
as fast, or faster. You don't know how long that function
is going to run (obviously).

On the other side of the argument, the embedded folks have
pointed out that you _want_ to always invoke those functions
(ie. avoid short circuiting) so that you can reliably
predict and measure your CPU overhead. This is particularly
important when you have a low margin of excess CPU
capability. This also improves code path coverage, for
testing purposes. Both of these reasons are important for
life critical pieces of software.

But for any _other_ situation (in the general purpose
programming arena), I see following reasons to
support short circuit expressions:

   1. When the extra clauses are invalid (ie. don't evaluate
      beyond a short-circuit when a pointer is known to be
      null, for example)

   2. For efficiency (avoid computing unnecessary results,
      particularly in function calls, where the overhead is
      known to be large enough to care about).

The fact that it exists in the language suggests to me that
some folks have valid uses for the construct. When someone
starts saying that you must always use, always not use
something, then I would have to question the reasoning
behind that.

Finally, it may also depend upon the portability of the
code. Programming to Pentium IV whims may really hurt
you on another quite different platform, depending upon
the application and the choices made.

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg