short-circuit control forms

short-circuit control forms

[James A. Krzyzanowski]

Looking for expert opinions...

We have a company standard which states:
"standard => Use short-circuit control forms to specify the order of
             conditions when the failure of one condition means that
             the other condition will raise an exception.
 guideline => Avoid short-circuit control forms otherwise."

Our software engineers believe that using short-circuit control forms
will make our software more efficient (speed-wise).  So, they have been
replacing every "and" with "and then" and every "or" with "or else".

We use Rational Apex and a Rational Representative sent correspondence
basically saying that their compiler will NOT optimize plain "and" and
"or" to behave as though the best "and then" and "or else" order has
been specified.

The reason for our standard on this topic is because we expected the
compiler to be smarter than the software engineer when it comes to
specifying an order of conditions.  This is also consistent with
Ada 95 Quality and Style: Guidelines for Professional Programmers.

If using "and then" and "or else" will make our software quicker, and
then the compiler doesn't optimize any better anyway, does anybody have
a good reason why we should NOT use short-circuit control forms?

-- 
---------------------------------------------------------------------------
         James A. Krzyzanowski - Staff Software Engineer - AFATDS       %c%
     Raytheon Systems Company * Fort Wayne, IN 46808 * (219) 429-6446   cus
                 mailto:James_A_Krzyzanowski@raytheon.com               %s%
---------------------------------------------------------------------------

Re: short-circuit control forms

[Ted Dennison]

In article <3B30F836.D700DAA3@raytheon.com>, James A. Krzyzanowski says...
>If using "and then" and "or else" will make our software quicker, and
>then the compiler doesn't optimize any better anyway, does anybody have
>a good reason why we should NOT use short-circuit control forms?

First off, its *not* assured that it will always be quicker. Since you are
replacing one branch with one branch for each condition, it will actually result
in *more* instructions being executed if it turns out that all the conditions
need to be applied. Depending on how many conditions there are and how much work
calculating them all is, in some cases the non-short-circuit form will execute
less code even when not all of the conditions are executed.

Another thing you have to consider is that most modern processors have a branch
prediction unit (BPU) that will do speculative execution to keep the instruction
pipeline filled when branches are encountered. If the "speculation" is
incorrect, the entire pipeline has to be flushed, which slows things down
greatly. Short-circuit forms generate more branch instructions, which can amount
to more chances for the BPU to guess wrong. Again, this may be trivial compared
to the chance of not executing a lot of extra code. But if the code in
calculating the conditions is small, or its usually all executed, then it can
matter.

Another important issue is maintanence. When someone unfamiliar with that code
first tries to read it, they are probably going to expect that there's some
*reason* that those short-circuit forms had to be used, and that there's some
reason that the conditionals are in the order they are in. As an example of a
problem that could cause, suppose one conditional needs to be split out for some
reason. That may lead to unnessecary complication of the code to preserve that
(presumed-important) ordering.

My last argument against this approach is philosophical, but relates directly to
all my previous points. As a general rule, you do *not* go about randomly
optimizing code, at the expense of complexity or readability. Programs generally
do not have their workload spread out evenly over the source, so this is an
incredibly bad use of man-hours (on both ends). The proper way to optimize is to
find a part that is running too slowly, find the slowest part of that, and see
what you can do to speed it up (then repeat until satisfied). Hand-optimization
should be done with tweezers and a microsope, not with a blindfold and a
sledgehammer. 

So unless there is some *verified* speed problem with a particular conditional,
write it the way in which it makes the most sense.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: short-circuit control forms

[Marin David Condic]

The first thing to ask is this: Are you *really* sure that whatever
inefficiency is introduced is going to matter? Many programmers have an
"efficiency fetish" (especially when they come out of a C programming mode)
that makes no sense in the target environment. I can't imagine a few extra
instructions in some condition checks are going to kill most programs. For
most apps it probably isn't even perceptable.

If that is the case, then the argument goes like this: "It isn't going to
hurt anything if you follow the written-down guidelines and the Ada95
Quality & Style guide. Future releases of the compiler may be able to do the
optimization for you (and do it better) and in the mean time, you will be
producing code that is remarkably like what our style guidelines dictate &
thus will make life easier for 'the other guy' when he has to read it. It
may also prevent hard to find errors in the code by forcing evaluation of
all conditions anyway. (Imagine a condition that *mostly* gets bypassed
because of an 'and then" and it isn't until some later point in the project
that the condition comes up - intermittently - causing some kind of runtime
error.)"

When you've got a situation where those few extra instructions are making a
difference in performance or threatening success of the project, then you go
ahead and pull every efficiency trick you can to get the code you need from
the compiler. That should be the *exception* to the style guide that is done
only where necessary.

Now if you want to debate the relative merits of what the style guide says -
that's another discussion. Someone might reasonably argue that this
guideline has no merit and should be abandoned. However that is a decision
that the development group as a whole should arrive at and not something
that should be violated by a lone wolf or two who just don't feel like
playing nice. The issue there is that if the style guide can just be
arbitrarily pitched by whoever wants to do so whenever they feel like it,
then what is the point of having one?

Managing programmers is like herding cats.

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/


"James A. Krzyzanowski" <James_A_Krzyzanowski@raytheon.com> wrote in message
news:3B30F836.D700DAA3@raytheon.com...
> Looking for expert opinions...
>
> We have a company standard which states:
> "standard => Use short-circuit control forms to specify the order of
>              conditions when the failure of one condition means that
>              the other condition will raise an exception.
>  guideline => Avoid short-circuit control forms otherwise."
>
> Our software engineers believe that using short-circuit control forms
> will make our software more efficient (speed-wise).  So, they have been
> replacing every "and" with "and then" and every "or" with "or else".
>
> We use Rational Apex and a Rational Representative sent correspondence
> basically saying that their compiler will NOT optimize plain "and" and
> "or" to behave as though the best "and then" and "or else" order has
> been specified.
>
> The reason for our standard on this topic is because we expected the
> compiler to be smarter than the software engineer when it comes to
> specifying an order of conditions.  This is also consistent with
> Ada 95 Quality and Style: Guidelines for Professional Programmers.
>
> If using "and then" and "or else" will make our software quicker, and
> then the compiler doesn't optimize any better anyway, does anybody have
> a good reason why we should NOT use short-circuit control forms?
>
> --
> --------------------------------------------------------------------------
-
>          James A. Krzyzanowski - Staff Software Engineer - AFATDS
%c%
>      Raytheon Systems Company * Fort Wayne, IN 46808 * (219) 429-6446
cus
>                  mailto:James_A_Krzyzanowski@raytheon.com
%s%
> --------------------------------------------------------------------------
-

Re: short-circuit control forms

[Jeffrey Carter]

"James A. Krzyzanowski" wrote:
> 
> Looking for expert opinions...
> 
> We have a company standard which states:
> "standard => Use short-circuit control forms to specify the order of
>              conditions when the failure of one condition means that
>              the other condition will raise an exception.
>  guideline => Avoid short-circuit control forms otherwise."
> 
> Our software engineers believe that using short-circuit control forms
> will make our software more efficient (speed-wise).  So, they have been
> replacing every "and" with "and then" and every "or" with "or else".
> 
> If using "and then" and "or else" will make our software quicker, and
> then the compiler doesn't optimize any better anyway, does anybody have
> a good reason why we should NOT use short-circuit control forms?

Do you know that using short-circuit forms makes your software quicker?

If you have measured the speed with and without the short-circuit forms,
and found it to be statistically different at the p=0.1 level or better
AND the difference is necessary for the software to function correctly,
then your software engineers are justified in their actions.

If not, you do not have software engineers. You have coders who are
wasting their time and the company's money on ignorant FUD, and
introducing a new source of error into working software. At best you
should fire them and replace them with software engineers; at worst you
should require them to adhere to your company standard unless they have
justification for deviating.

-- 
Jeffrey Carter

Re: short-circuit control forms

[Mark Lundquist]

"James A. Krzyzanowski" <James_A_Krzyzanowski@raytheon.com> wrote in message
news:3B30F836.D700DAA3@raytheon.com...
> Looking for expert opinions...
>
> We have a company standard which states:
> "standard => Use short-circuit control forms to specify the order of
>              conditions when the failure of one condition means that
>              the other condition will raise an exception.
>  guideline => Avoid short-circuit control forms otherwise."
>

That sounds like a good standard, modulo the issue of how to handle
side-effects in functions (let's not go there...)

> Our software engineers believe that using short-circuit control forms
> will make our software more efficient (speed-wise).  So, they have been
> replacing every "and" with "and then" and every "or" with "or else".

I would say that's not good practice (see below)...

>
> We use Rational Apex and a Rational Representative sent correspondence
> basically saying that their compiler will NOT optimize plain "and" and
> "or" to behave as though the best "and then" and "or else" order has
> been specified.
>
> The reason for our standard on this topic is because we expected the
> compiler to be smarter than the software engineer when it comes to
> specifying an order of conditions.  This is also consistent with
> Ada 95 Quality and Style: Guidelines for Professional Programmers.
>
> If using "and then" and "or else" will make our software quicker, and
> then the compiler doesn't optimize any better anyway, does anybody have
> a good reason why we should NOT use short-circuit control forms?

OK...

First of all, rewriting all conditionals this way is not necessarily an
optimization.  It all depends on what the expressions are, and whether there
is an "expected case".  The notion that short circuit forms are always
faster is an oversimplification.

Then, supposing you did get a net speedup if everyone did this... would it
be worth it?  Someone might say, "well, it can't hurt," (but see above),
"and as long as I'm in the neighborhood here, I might as well do it".  But
those changes don't quite come for free:

- Readers of code reasonably assume that things are the way they are for a
reason.  I don't think "we thought short circuit forms were faster" counts
as a good reason, and so I would expect that most readers would get the
impression that there is some other reason why it must be that way.  If it's
not really true, then the intent is obscured and the understanding process
is slowed down.

- Blindly replacing like this *is* error-prone, because you have to make
sure you're not losing side-effects that change the behavior of the program.
If there is cost to verifying this, then that's part of the cost of making
the change.

- If the programmer is checking in the change as part of another change, it
leaves the impression that it was necessary for whatever development
activity the new version is required for.  Again, confusing.

- Alternatively, they might try to "keep it clean", and create a new version
just for changing an "and" to an "and then" or whatever (I'll bet they don't
do that, but...:-)  But now we are creating a new version for a performance
difference that might only be marginally better.  The new version is subject
to the change propagation process.  And every additional version makes it a
little more difficult to follow the change log.  So there is a cost.

- If you added up all the time that programmers spend doing dubious
hand-optimizations, there's some opportunity cost there... they could
instead be doing hand-optimization the right way, which is to measure and
find out where the bottlenecks are, then figure out how to make those
bottlenecks *significantly* faster.

- Lastly, you have a standard in place, and programmers who are blowing it
off for their own reasons.  So the organization should do one of three
things: (a) say "Who needs a standard, anyway?" and chuck it; (b) say, "Our
standard is broken, let's fix it" (if that were the case :-); or, (c) tell
the programmers they need a better reason to blow off the standard, and to
quit going off half-cocked.  A good way might be to require some formality
for exceptions to your guideline.  That ought to cure them of this
tendency...

Have fun,
Mark Lundquist

Re: short-circuit control forms

[Al Christians]

Jeffrey Carter wrote:
> 
> If not, you do not have software engineers. You have coders who are
> wasting their time and the company's money on ignorant FUD, and
> introducing a new source of error into working software. 

I'll admit to most of that.  But, I find that it is a common
thinkographical error for me to not realize that the second condition
will be evaluated even when irrelevant, and that it often works 
out that an exception is raised when the second condition is
evaluated.   That probably comes from too much time coding in other
languages in which the short-circuitedness is controlled by a compiler
option that is typically set to short-circuit.   IOW, when programming
unconsciously, I am more likely to write a correct program if I
habitually use the short-circuit forms than if I don't.   Following
this style will also serve as a form of negative encouragement for 
functions with side effects, which is also good.  


Al

Re: short-circuit control forms

[Al Christians]

Mark Lundquist wrote:
> 
> - If the programmer is checking in the change as part of another 
> change, it leaves the impression that it was necessary for whatever 
> development activity the new version is required for.  Again, > confusing.
> 

Attempting to solve multiple problems in the same set of check-ins 
ought to be cumpulsory to avoid.  It's dirty pool to plop that pastry
into an otherwise irrelevant thread.


Al

Re: short-circuit control forms

[Larry Kilgallen]

In article <b%aY6.212292$p33.4300386@news1.sttls1.wa.home.com>, "Mark Lundquist" <up.yerz@nospam.com> writes:

> - Blindly replacing like this *is* error-prone, because you have to make
> sure you're not losing side-effects that change the behavior of the program.
> If there is cost to verifying this, then that's part of the cost of making
> the change.
> 
> - If the programmer is checking in the change as part of another change, it
> leaves the impression that it was necessary for whatever development
> activity the new version is required for.  Again, confusing.

If there is any such confusion, the checkin should be rejected by the
reviewer as being insufficiently commented.

Re: short-circuit control forms (& 'long names are doom')

[Paul Graham]

"James A. Krzyzanowski" wrote:
> 
> Looking for expert opinions...
> 
> We have a company standard which states:
> "standard => Use short-circuit control forms to specify the order of
>              conditions when the failure of one condition means that
>              the other condition will raise an exception.
>  guideline => Avoid short-circuit control forms otherwise."
> 

Looking at the GNAT 3.13p source code, I count about 5000 occurrences of
'and then' and only about 400 occurrences of 'and' not followed by
'then'.  (This count is very approximate.)  It seems that the GNAT
policy is to use 'and then' by default.

Regarding the 'long names are doom' thread, I also notice that GNAT
tends to use short names. For instance, rather than using Integer
everywhere, many modules use subtype 'int' (though this may be for C
compatibility).  Another example of short names is the use of 'N' and
'M', sometimes for Node_Id, sometimes as integers.  Another example is
the use of single letter loop indices.  There are about 1700 'for' loops
in the GNAT source code, about 1600 of which use single letter indices. 
There are also short routine names, such as 'Scan', which, had it been
written 15 years ago, would have been called
'Scan_For_Next_Token_In_Input_Stream'.  There are about 50 declarations
of functions and procedures with single-character names, about 50 with
two-character names, and almost 300 with three-character names (though
some of these are the three-character transcendental functions Sin, Cos,
etc.).  Of course, there are plenty of long identifiers in GNAT, but
clearly the project does not prohibit the use short names.

Paul

Re: short-circuit control forms

[Wes Groleau]

> - Readers of code reasonably assume that things are the way they are for a
> reason.  I don't think "we thought short circuit forms were faster" counts
> as a good reason, and so I would expect that most readers would get the
> impression that there is some other reason why it must be that way.  If it's
> not really true, then the intent is obscured and the understanding process
> is slowed down.

This is similar to the rationale for our standards/guidelines.
Since the RM, AQS, and most Ada textbooks say that the purpose
of a short-circuit is to avoid an exception in the second test,
using the form without comment is telling future readers that
this situation exists.  If that message is not true....

And, as others have pointed out.... anyone remember who
said (not an exact quote):

   More computing sins have been committed in the name
   of efficiency (without actually acheiving it) ..."

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: short-circuit control forms

[Wes Groleau]

> > If not, you do not have software engineers. You have coders who are
> 
> I'll admit to most of that.  But, ..... when programming
> unconsciously, I am more likely to write a correct program if I
> habitually use the short-circuit forms than if I don't.   

If you are programming unconsciously, you are not
doing software engineering.  :-)

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: short-circuit control forms

[Al Christians]

Wes Groleau wrote:
> 
> 
> If you are programming unconsciously, you are not
> doing software engineering.  :-)
> 

Sure.  A software engineering project shouuld give explicit 
consideration to all four possibilities:  true & true, true & 
false, false & true, false & false.  But when someone is trying 
to write and think at the same time: 'if A and ...' their mind 
is focused by the form of the statement into thinking about what 
else  has to be true besides A for the action to be the right 
action.  You can't have too many things in mind at the same time, 
and what happens if A is not true is easily excluded from 
consideration as you write that statement. 

The argument against automatically including the safety mechanism of 
'and then' as the normal form is that it is misleading to someone 
trying to draw inferences about preconditions from the code.  If one 
is doing the 'software engineering' you mention, why is one trying 
to draw inferences about preconditions from the code? Don't 'software 
engineering' projects generate 5-20 pages of documentation and 
related paperwork per line of  code?  Isn't the information about 
the preconditions going to be properly recorded somewhere in those 
documents? If code is not documentation, why does 'software 
engineering' mean that we have to code like it is, even to the 
point of worrying about the possible but completely unjustified 
inferences that may be drawn by some future code reader? 

Wouldn't the best approach be to use 'and' most in testing, so that 
as many exceptions as possible are detected in testing, but use 
'and then' most in the delivered code, so that as few exceptions 
as possible are detected by the customer?


Al

Re: short-circuit control forms (& 'long names are doom')

[Warren W. Gay VE3WWG]

Paul Graham wrote:
> "James A. Krzyzanowski" wrote:
> >
> > Looking for expert opinions...
> >
> > We have a company standard which states:
> > "standard => Use short-circuit control forms to specify the order of
> >              conditions when the failure of one condition means that
> >              the other condition will raise an exception.
> >  guideline => Avoid short-circuit control forms otherwise."
> >
> 
> Looking at the GNAT 3.13p source code, I count about 5000 occurrences of
> 'and then' and only about 400 occurrences of 'and' not followed by
> 'then'.  (This count is very approximate.)  It seems that the GNAT
> policy is to use 'and then' by default.

Before arriving at that assumption, did you examine how many of those
cases NEEDED to be that way? Since you didn't report a count of those,
then I think we can safely assume that you didn't check that.

It has been pointed out by many, that the spirit of the short-circuit
forms is to avoid exceptions in evaluating the rest of the expression.
If this is the case, then these are perfectly valid uses of the
short-circuit forms.

-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

Re: short-circuit control forms

[Wes Groleau]

> > If you are programming unconsciously, you are not
> > doing software engineering.  :-)

Just teasing--note the smiley.  On the other hand....

> Wouldn't the best approach be to use 'and' most in testing, so that
> as many exceptions as possible are detected in testing, but use
> 'and then' most in the delivered code, so that as few exceptions
> as possible are detected by the customer?

No.  If an exception is found in testing, handle it or fix it.
Don't obfuscate the code just to hide exceptions you didn't find
yet.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: short-circuit control forms (& 'long names are doom')

[Wes Groleau]

> > Looking at the GNAT 3.13p source code, I count about 5000 occurrences of
> > 'and then' and only about 400 occurrences of 'and' not followed by
> > 'then'.  (This count is very approximate.)  It seems that the GNAT
> > policy is to use 'and then' by default.
> 
> Before arriving at that assumption, did you examine how many of those
> cases NEEDED to be that way? Since you didn't report a count of those,
> then I think we can safely assume that you didn't check that.

On top of that, with no disrespect intended toward the fine folks at
ACT, it would be rather foolish for us to base our company standard
on the behavior of one company (whether or not that behavior
complies with that company's standard).  Especially when that company
specializes in a different application domain than we do.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: short-circuit control forms

[Marin David Condic]

If you change the code, then you didn't test what you deliver. It is
generally considered to be A Bad Thing in the mission critical world to run
your tests, modify the code, then deliver it. If you aren't playing in this
field, then the whole efficiency argument goes up in smoke anyway - so you
don't want to waste time fooling with the and thens.

However, I can see your point about minimizing the exposure to possible
undetected errors. Still, I would prefer to fix the errors up front - or
never put them in to begin with. But that starts opening up the question of
what level of testing is good enough? And is it better for your reputation
to have an occasional flakey error cause a system crash and have enormous
difficulty reproducing the conditions for you to detect & correct it or is
it better to have more frequent crashes in early deliveries and have an
easier time of detecting the problems & fixing them?  (Presuming, of course,
that this isn't Mission Critical software we're discuissing.) I think it
might depend on your individual situation. (In house customer vs general
public, cost of failures, etc.)

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/


"Al Christians" <achrist@easystreet.com> wrote in message
news:3B3216D9.113A612B@easystreet.com...
> Wouldn't the best approach be to use 'and' most in testing, so that
> as many exceptions as possible are detected in testing, but use
> 'and then' most in the delivered code, so that as few exceptions
> as possible are detected by the customer?
>

Re: short-circuit control forms (& 'long names are doom')

[Charles Hixson]

Long Names:  I tend to avoid long names, as long as I can come 
up with a suitable short name.  str_ptr has no need to be 
renamed into String_Pointer.  In fact, usually sPtr would be 
quite clear in context.  And compact code that is clear is 
easier to debug than verbose code that says exactly the same 
thing.
But don't forget the caveat.  If the name isn't clear, then it 
needs to be longer.  Or perhaps just totally redesigned.  (And 
when figuring out what is clear, have pity on the maintenance.)

Short-Cut Booleans:  Sometimes these are mandatory.  They rarely 
do harm in current code.  But they may limit the optimization 
that will be possible in the future.  I can quite imagine a 
compiler that decides that a multi-processor should run the 
logic tests in parallel, unless they were simple expressions or 
short-cut forms.  And in a few years, this may be significant.  
OTOH, short-cut forms make the code more deterministic, so 
perhaps another kind of optimization becomes easier.  And they 
should make correctness proofs easier (fewer paths to examine).

I generally only use short-cut booleans where they are needed.

-- 
Charles Hixson

Copy software legally, the GNU way!
Use GNU software, and legally make and share copies of software.
See http://www.gnu.org
    http://www.redhat.com
    http://www.linux-mandrake.com
    http://www.calderasystems.com/
    http://www.linuxapps.com/

Re: short-circuit control forms (& 'long names are doom')

[Larry Kilgallen]

In article <Xns90C7A5EA1B78Dcharleshixsonearthli@207.217.77.21>, Charles Hixson <charleshixson@earthling.net> writes:

> Short-Cut Booleans:  Sometimes these are mandatory.  They rarely 
> do harm in current code.  But they may limit the optimization 
> that will be possible in the future.  I can quite imagine a 
> compiler that decides that a multi-processor should run the 
> logic tests in parallel, unless they were simple expressions or 
> short-cut forms.

There is no need to look to the future or restrict the venue only to
multiprocessors.  Some modern uniprocessor systems have chips that
are capable of "out of order" execution.  Compilers for such machines
must take explicit action to prevent this if mandated by shortcut
bookean expressions.

Re: short-circuit control forms (& 'long names are doom')

[DuckE]

There was an interesting thread on this subject back in 95 (search for short
circuit in the Google archives of comp.lang.ada).

I found Tucker Taft's comment particularly interesting:

": If both operands are
 : always evaluated, does that mean that whenever it is unnecessary to
 : evaluate the second operand, one should use the short-circuit operators
 : for efficiency?

 To avoid depending on the quality of your compiler's optimizer,
 I personally recommend using short-circuit operations by default,
 and only use "and" or "or" when it is *required* that both
 operands be evaluated.

 Of course, a clever optimizer can actually evaluate both
 operands even though a short circuit is specified, so long
 as there are no side-effects (including possibilities for
 exceptions).  For example, if A and B are boolean variables,
 then a compiler might decide it is more efficient to just
 "and" them together even when "and then" is specified,
 to avoid the extra conditional branches.

 Hence, if your compiler is clever, it doesn't matter what you
 do since it will un-do it if appropriate, and if your compiler is
 not clever, then using short-circuit by default probably produces
 somewhat better code quality on average.

Re: short-circuit control forms

[Marc A. Criley]

Marin David Condic wrote:
> 
> However, I can see your point about minimizing the exposure to possible
> undetected errors. Still, I would prefer to fix the errors up front - or
> never put them in to begin with. But that starts opening up the question of
> what level of testing is good enough? And is it better for your reputation
> to have an occasional flakey error cause a system crash and have enormous
> difficulty reproducing the conditions for you to detect & correct it or is
> it better to have more frequent crashes in early deliveries and have an
> easier time of detecting the problems & fixing them?  (Presuming, of course,
> that this isn't Mission Critical software we're discuissing.) I think it
> might depend on your individual situation. (In house customer vs general
> public, cost of failures, etc.)

The original version of a shipboard weapon control system I worked on
had myriad exception handlers and checks for conditions that should not
have been able to occur, but did, and so were trapped and worked
around.  Needless to say, with the root causes left unaddressed, over
time the system's operation got more and more corrupt and degraded,
until it finally couldn't hold up any more, and would just lock up or
crash.

In the redesign of that system, exception handlers were permitted only
for those exceptions whose raising was anticipated as part of "normal"
failure operations.  And work-arounds to handle anomalous occurrences
were strictly barred.  As a result, the system under development crashed
more frequently than the extensively band-aided one it was going to
replace.

This caused consternation amongst program management, because they
thought the redesigned system was supposed to be better than the
original.  At the last presentation I made to the customer I explained
why we were getting the crashes:  We were finding the bugs _now_,
instead of following the previous practice of having the test group
uncover them and send problem reports back through a longer analyze and
fix cycle.  Our streamlined fix/test process was turning around bug
reports in a day.  And instead of patching and hoping it would hold
through test, we were getting close to having a twisted view of system
crashes--we almost liked them, because it flushed out another bug and we
had scads of log data available to quickly zero in on and fix the
problem.

When we delivered the system a few weeks later, there was only one
low-priority bug report open against the system, and it was an order of
magnitude better in performance, reliability, and understandability than
its predecessor.

Marc A. Criley
Senior Staff Engineer
Quadrus Corporation
www.quadruscorp.com

Re: short-circuit control forms

[Marin David Condic]

Exception handlers can definitely be used to sweep problems under the rug.
When I was building a rocket engine control where failure was not an option,
we only had exception handling at the outer-most control loops because if an
exception got to that point, you were either going to reboot the box
(possibly in mid-burn and blow the mission) or you were going to try to
ignore whatever caused it and press on hoping that the control would do
something reasonable to keep the rocket going. Naturally, we logged any
occurence of any exception in memory and could monitor this via test
monitoring equipment and telemetry. I'm pleased to say it never came up as
an issue - we never had an exception - but it *could* have masked a real
problem during testing. (Of course, for efficiency, we had to turn off most
runtime checks, but that didn't mean you couldn't get any exceptions - or
that this was the best way to build software. I'd have liked to leave the
checks in so we'd know if there were problems in the code, rather than let
them get into the field, but compromises must be made sometimes.)

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/

"Marc A. Criley" <mcqada@earthlink.net> wrote in message
news:3B332A96.64DDB78E@earthlink.net...
>
> The original version of a shipboard weapon control system I worked on
> had myriad exception handlers and checks for conditions that should not
> have been able to occur, but did, and so were trapped and worked
> around.  Needless to say, with the root causes left unaddressed, over
> time the system's operation got more and more corrupt and degraded,
> until it finally couldn't hold up any more, and would just lock up or
> crash.
>
> In the redesign of that system, exception handlers were permitted only
> for those exceptions whose raising was anticipated as part of "normal"
> failure operations.  And work-arounds to handle anomalous occurrences
> were strictly barred.  As a result, the system under development crashed
> more frequently than the extensively band-aided one it was going to
> replace.
>
> This caused consternation amongst program management, because they
> thought the redesigned system was supposed to be better than the
> original.  At the last presentation I made to the customer I explained
> why we were getting the crashes:  We were finding the bugs _now_,
> instead of following the previous practice of having the test group
> uncover them and send problem reports back through a longer analyze and
> fix cycle.  Our streamlined fix/test process was turning around bug
> reports in a day.  And instead of patching and hoping it would hold
> through test, we were getting close to having a twisted view of system
> crashes--we almost liked them, because it flushed out another bug and we
> had scads of log data available to quickly zero in on and fix the
> problem.
>
> When we delivered the system a few weeks later, there was only one
> low-priority bug report open against the system, and it was an order of
> magnitude better in performance, reliability, and understandability than
> its predecessor.
>
> Marc A. Criley
> Senior Staff Engineer
> Quadrus Corporation
> www.quadruscorp.com

Re: short-circuit control forms (& 'long names are doom')

[Wes Groleau]

> There was an interesting thread on this subject back in 95 (search for short
> circuit in the Google archives of comp.lang.ada).

Didn't work.  Seeral search methods only returned parts
of this (current) thread.

> I found Tucker Taft's comment particularly interesting:
> 
> ": If both operands are
>  : always evaluated, does that mean that whenever it is unnecessary to
>  : evaluate the second operand, one should use the short-circuit operators
>  : for efficiency?

I hope he's listening, because without seeing the whole post,
I strongly suspect that his answer was "no"

>  To avoid depending on the quality of your compiler's optimizer,
>  I personally recommend using short-circuit operations by default,
>  and only use "and" or "or" when it is *required* that both
>  operands be evaluated.

I do not recommend "depending on" the optimizer, but
I recommend even more strongly NOT disabling the optimizer.

>  Hence, if your compiler is clever, it doesn't matter what you
>  do since it will un-do it if appropriate, and if your compiler is

If  _allowed_  and appropriate.

>  not clever, then using short-circuit by default probably produces
>  somewhat better code quality on average.

For reasons already stated in this thread, I doubt it.  That's if
you define "code quality" as "efficient."  If you define it as clear,
readable, and less error-prone, then for reasons already stated
in this thread, I doubt it.

What surprises me the most about our "profession" in general
is the fact that the folks "in the trenches" habitually ignore
the good advice of the "experts" that we claim to respect.

Since nearly THIRTY YEARS AGO (and probably longer), folks have
known and written of the foolishness of misguided "optimization"
efforts (emphasis mine):

   Kernighan & Plauger, 1974.  Elements of Programming Style:

     Make it right _before_ you make it faster.

     _Keep_it_right_ when you make it faster.

     Make it clear _before_ you make it faster.

     Don't sacrifice _clarity_ for small gains in "efficiency."

     Let your _compiler_ do the simple optimizations.

     Keep it _simple_ to make it faster.
        [I have fixed at least as many bugs by
         _removing_ code as I have by adding code. -WWG]

     Don't diddle code to make it faster � find a better algorithm.

     Instrument your programs.  _Measure_ before making "efficiency" changes.

   Ledgard, Nagin, Hueras, 1979.
   Pascal with Style: Programming Proverbs:

     Shortening the code, running the program faster,
     or using fewer variables are all popular pastimes. .....
     Not mentioning ... the extra testing time needed
     to check the new and often subtle boundary conditions,
     are you _sure_ that fewer machine instructions or
     faster machine execution is likely?

   Some others which I have not been able to verify the sources of:

     Rules of Optimization:
     Rule 1: Don't do it.
     Rule 2 (for experts only): Don't do it yet.
        - M.A. Jackson

     "More computing sins are committed in the name of efficiency
     (without necessarily achieving it) than for any other single
     reason - including blind stupidity."
        - W.A. Wulf

     "We should forget about small efficiencies, say about 97% of
     the time: premature optimization is the root of all evil."
        - Donald Knuth

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: short-circuit control forms (& 'long names are doom')

[Ted Dennison]

In article <3B336844.9B58ED9A@ftw.rsc.raytheon.com>, Wes Groleau says...
>
>
>> There was an interesting thread on this subject back in 95 (search for short
>> circuit in the Google archives of comp.lang.ada).
>
>Didn't work.  Seeral search methods only returned parts
>of this (current) thread.

Damn. I tried posting links to that thread yeseterday, but my message seems to
have been lost in the ether. I'll look for it and try again.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: short-circuit control forms (& 'long names are doom')

[Ted Dennison]

In article <3B336844.9B58ED9A@ftw.rsc.raytheon.com>, Wes Groleau says...
>
>
>> There was an interesting thread on this subject back in 95 (search for short
>> circuit in the Google archives of comp.lang.ada).
>
>Didn't work.  Seeral search methods only returned parts
>of this (current) thread.

The top of the thread in google can be found at
http://groups.google.com/groups?&th=8b7a8d2b810c767b,15&start=0&ic=1 .


>> I found Tucker Taft's comment particularly interesting:
( http://groups.google.com/groups?th=8b7a8d2b810c767b,15&start=3&ic=1 )

>I hope he's listening, because without seeing the whole post,
>I strongly suspect that his answer was "no"

You'd be wrong. :-(

The general gist I got from the thread is that both Tucker and Robert Dewar
agreed that this is mostly a religous issue, and that both of them subsribe to
short-circuitism. Robert said (in
http://groups.google.com/groups?th=8b7a8d2b810c767b,15&start=6&ic=1 ):

>I personally prefer the second style, but in any case it is clear
>that you need to choose one particular style and stick to it. For
>example, GNAT always uses the second style.

"second style" being using short-circuit forms by default.


---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: short-circuit control forms (& 'long names are doom')

[Robert Dewar]

"DuckE" <nospam_steved94@home.com> wrote in message news:<QGyY6.222270$p33.4459972@news1.sttls1.wa.home.com>...

The GNAT standard is to use AND THEN/OR ELSE for all cases except
when simple Boolean values are involved.

We never have a situation where both operands *must* be evaluated,
since this would represent disgusting coding with side effects, so
we do not have a rule that covers this case :-)

Re: short-circuit control forms (& 'long names are doom')

[Robert Dewar]

Wes Groleau <wwgrol@ftw.rsc.raytheon.com> wrote in message news:<3B336844.9B58ED9A@ftw.rsc.raytheon.com>...
> Since nearly THIRTY YEARS AGO (and probably longer), folks have
> known and written of the foolishness of misguided "optimization"
> efforts (emphasis mine):

My preference for using the short circuited forms has nothing to do
with efficiency, it has to do with readability. My feeling is that
in English, the short circuited semantics are natural. if you are in
an airport, and you hear an announcement that says "All passengers
on China airlines flight 182 to Beijing who are holding .......

You can stop listening to the announcement at or slightly before the
.... (you might stop right after China :-) You do not listen to
all parts of this announcement, consider whether each part applies
to you, and then say, gosh, of those 7 things, 6 are true for me,
but I am not on flight 182, so I don't need to proceed to gate 36 :-)

On the other hand when it comes to Boolean variables

   if a or b then

then the short circuit form seems to me to read oddly, and I prefer the
simple OR, again, nothing whatever to do with optimization.

Re: short-circuit control forms

[Robert Dewar]

Jeffrey Carter <jeffrey.carter@boeing.com> wrote in message news:<3B312260.728686B5@boeing.com>...
> If not, you do not have software engineers. You have coders who are
> wasting their time and the company's money on ignorant FUD, and
> introducing a new source of error into working software. At best you
> should fire them and replace them with software engineers; at worst you
> should require them to adhere to your company standard unless they have
> justification for deviating.


The above itself is FUD in this case.

It is quite obvious that in some cases short circuiting is critical
for efficiency without needing detailed measurements. For example, 
when searching in a binary tree, it can make the difference between
O(logN) and O(N) behavior in extreme cases (well in recursion cases
it can of course make the difference between finite and infinite
execution time in a non-lazy language).

Re: short-circuit control forms

[Ted Dennison]

In article <5ee5b646.0106221258.601d2bce@posting.google.com>, Robert Dewar
says...
>It is quite obvious that in some cases short circuiting is critical
>for efficiency without needing detailed measurements. For example, 
>when searching in a binary tree, it can make the difference between
>O(logN) and O(N) behavior in extreme cases (well in recursion cases

But if the binary tree isn't ever that large, then it might not be "critical for
efficiency" at all. However, in this case I'd agree with you completely that you
should probably still go with the short-circuit in the first place. 

Then again, this is a bit of a strawman argument. What are you doing using a
binary-tree instead of a simple linear linked-list in the first place, if the
performance hasn't already been determined to be "critical for efficiency"? It
seems in this case you have already started looking at efficiency, so its fairly
easy to agree with you that this is a case where its sensible to keep such
details in mind.

I have to wonder how much of the sides people take on this issue has to do with
the kind of applications they generally develop. The short-circuitist approach
does have the benifit of minimizing *average* runtime for an application. That
is a damn important number for anyone writing CPU-limited input processing
application like a compiler. However, for us folks doing real-time work, we
don't care at all about that number. What we have to worry about is meeting a
deadline in the *worst* case (or the deadline - our targeted spare). If we do
meet that deadline, great. If we don't, its usually due to one or two horribly
inneficient constructs somewhere in a tight loop, and the odds of it being a
non-short-circuit is pretty slim (could happen, but I haven't see it yet). The
other problem we have to deal with occasionaly is jitter (a routine taking a
variying time to complete, causing noticeble time variations somewhere else).
That issue is actualy made a smidge *worse* using a short-circuited construct.

Anyway, it seems that, of the positions I can identify, the most vocal
short-circuitists are compiler writers, and the most vocal nonshort-circuiters
are real-time programmers. But perhaps my analysis is a bit off, and the truth
of the matter is that you compiler writers just happen to be much more
knowledgable than us real-time developers. After all, at you are at least smart
enough to work on a system that can be used and debugged on your host machine.
We have to walk over to labs or fly halfway around the world just to try out our
code properly. How stupid is that? :-)

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: short-circuit control forms (& 'long names are doom')

[Jerry Petrey]

Robert Dewar wrote:
> 
> "DuckE" <nospam_steved94@home.com> wrote in message news:<QGyY6.222270$p33.4459972@news1.sttls1.wa.home.com>...
> 
> The GNAT standard is to use AND THEN/OR ELSE for all cases except
> when simple Boolean values are involved.
> 
> We never have a situation where both operands *must* be evaluated,
> since this would represent disgusting coding with side effects, so
> we do not have a rule that covers this case :-)


Welcome back Robert.  I like your answer to this.
I was wondering when someone was going to say something
about functions with side effects not being a good thing.
Unfortunately, in my current application that I inherited,
that are a ton of them but I would sure hate to have a
coding standard that encouraged them.

Jerry
-- 
-----------------------------------------------------------------------------
-- Jerry Petrey                                                
-- Senior Principal Systems Engineer - Navigation, Guidance, & Control
-- Raytheon Missile Systems          - Member Team Ada & Team Forth
-- NOTE: please remove <NOSPAM> in email address to
reply                  
-----------------------------------------------------------------------------

Re: short-circuit control forms

[Jeffrey Carter]

Robert Dewar wrote:
> 
> Jeffrey Carter <jeffrey.carter@boeing.com> wrote in message news:<3B312260.728686B5@boeing.com>...
> > If not, you do not have software engineers. You have coders who are
> > wasting their time and the company's money on ignorant FUD, and
> > introducing a new source of error into working software. At best you
> > should fire them and replace them with software engineers; at worst you
> > should require them to adhere to your company standard unless they have
> > justification for deviating.
> 
> The above itself is FUD in this case.
> 
> It is quite obvious that in some cases short circuiting is critical
> for efficiency without needing detailed measurements. For example,
> when searching in a binary tree, it can make the difference between
> O(logN) and O(N) behavior in extreme cases (well in recursion cases
> it can of course make the difference between finite and infinite
> execution time in a non-lazy language).

It may well be true that short circuiting is necessary to obtain
acceptable run times when implementing a search in a binary tree, but
that seems to have no bearing on the subject under discussion. The post
that I was replying to described coders changing working Ada, which
implies that the software is already fast enough, because they believe
that short circuit forms are universally faster, without any evidence
that their beliefs are true. To change working software in a manner
known to be a potential source of errors without any evidence of
benefit, much less of necessary benefit, does not seem justifiable to
me.

I guess this means the above is FUD about FUD about FUD. Shall we try
for FUD ** 4?

Do your posts this afternoon represent situations you thought it very
important to comment on, or can we expect the pleasure of your posts on
a regular basis again?

-- 
Jeffrey Carter

Re: short-circuit control forms

[Larry Kilgallen]

In article <3B33CD82.328E3182@boeing.com>, Jeffrey Carter <jeffrey.carter@boeing.com> writes:

> It may well be true that short circuiting is necessary to obtain
> acceptable run times when implementing a search in a binary tree, but
> that seems to have no bearing on the subject under discussion. The post
> that I was replying to described coders changing working Ada, which
> implies that the software is already fast enough, because they believe
> that short circuit forms are universally faster,

Presumably this was in preparation for switching to a slower machine :-)

Re: short-circuit control forms

[Simon Wright]

Jeffrey Carter <jeffrey.carter@boeing.com> writes:

>                              To change working software in a manner
> known to be a potential source of errors without any evidence of
> benefit, much less of necessary benefit, does not seem justifiable to
> me.

Well, I would leave out "in a manner known to be a potential source of
errors"!

-S

Re: short-circuit control forms (& 'long names are doom')

[Marin David Condic]

I wouldn't exactly call it "disgusting". There are situations in which it
makes sense. As was brought up elsewhere, when dealing with tight timing
considerations (efficiency being the reason this was brought up in the first
place) or high reliability requirements, you may want to force all
conditions to be evaluated to avoid timing variations and/or to increase
path coverage when testing.

I would agree that generally speaking, one would want to avoid side-effects
when writing conditional tests. This is the sort of abomination often seen
in C programs that makes it difficult to understand & debug the code. (Also
one of the reasons you had to "debug" it in the first place, rather than
just run it.) But avoidance is not exactly the same as "never". (Example:
"if (X = Pseudo_Random_Number (Something)) then...")

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/


"Robert Dewar" <dewar@gnat.com> wrote in message
news:5ee5b646.0106221243.3617111a@posting.google.com...
> "DuckE" <nospam_steved94@home.com> wrote in message
news:<QGyY6.222270$p33.4459972@news1.sttls1.wa.home.com>...
> We never have a situation where both operands *must* be evaluated,
> since this would represent disgusting coding with side effects, so
> we do not have a rule that covers this case :-)

Re: short-circuit control forms

[Wes Groleau]

> It is quite obvious that in some cases short circuiting is critical
> for efficiency without needing detailed measurements. For example,

More than one person has stated (some with persuasive explanations)
that a short-circuit form can be slower or the same depending on
the application or compiler or processor.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: short-circuit control forms

[Wes Groleau]

> that seems to have no bearing on the subject under discussion. The post
> that I was replying to described coders changing working Ada, which
> implies that the software is already fast enough, because they believe
> that short circuit forms are universally faster, without any evidence
> that their beliefs are true. To change working software in a manner

To be more specific, this is "working Ada" for which size
is more of an issue than execution speed.  That changes a lot,
doesn't it?

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau