comp.lang.ada
 help / color / mirror / Atom feed
From: munnari.oz.au!yoyo.aarnet.edu.au!news.adelaide.edu.au!usenet@uunet.uu.net (Andrew Dunstan,,2285592,)
Subject: Re: and then
Date: 8 Apr 93 22:35:25 GMT	[thread overview]
Message-ID: <1q29bd$7d8@huon.itd.adelaide.edu.au> (raw)

>From article <1993Apr7.162133.3564@nosc.mil>, by sampson@nosc.mil (Charles H. 
Sampson):
[ should we always use short-circuit boolean forms?]
> 
>      My style is to use the boolean operators generally, reserving the
> short-circuit forms to document that the second operand should not be eval-
> uated under some circumstances.
> 

Your style is correct. Your reservations (see below) are not. Still,
it's better to do the right thing for the wrong reason than the other
way around :-)


>      Unfortunately, that style can conflict with efficiency considerations. 
> Ada compiler writers appear to have abdicated their responsibility and make
> no attempt to determine when boolean operations can be optimized as short-
> circuit.  (Somebody contradict me, please.)  They apparently feel that if
	     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
	     OK.

> the programmer wants short-circuit he can ask for it.  In addition, there
> are cases when it is unreasonable to expect such an optimization; when the
> second operand contains a function reference, for example.
> 

The LRM (4.5.5) says: the operands of an expression that does not
contain a short-circuit control form are evaluated in some order that
is not defined by the language (but before application of the
corresponding operator).

So, the compiler writers are correct in not attempting to cast
non-short circuit forms to short-circuit evaluation. 

There could well be cases where evaluation of both operands is wanted
(if evaluation of one or both has a desired side-effect). If so,
"optimising" evaluation of one away is highly undesirable.

Leaving the order undefined also ALLOWS the compiler writer the chance
to optimise the order of evaluation.

In summary, if you want short-circuit, ask for it. If not, let the
compiler do the evaluation of both operands the best way it can.

#  Andrew Dunstan                   #   There's nothing good or bad   #
#  net:                             #                                 #
#    adunstan@steptoe.adl.csa.oz.au #   but thinking makes it so.     #
#  or: andrewd@cs.adelaide.edu.au   #                                 #
 
#  Andrew Dunstan                   #   There's nothing good or bad   #
#  net:                             #                                 #
#    adunstan@steptoe.adl.csa.oz.au #   but thinking makes it so.     #
#  or: andrewd@cs.adelaide.edu.au   #                                 #

             reply	other threads:[~1993-04-08 22:35 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1993-04-08 22:35 Andrew Dunstan,,2285592, [this message]
  -- strict thread matches above, loose matches on Subject: below --
1993-04-12 18:38 and then Charles H. Sampson
1993-04-12 13:29 cis.ohio-state.edu!zaphod.mps.ohio-state.edu!howland.reston.ans.net!noc.n
1993-04-11  3:55 Michael Feldman
1993-04-10 19:52 Alex Blakemore
1993-04-10 15:43 Dik T. Winter
1993-04-10 15:36 Dik T. Winter
1993-04-10  9:39 munnari.oz.au!yoyo.aarnet.edu.au!news.adelaide.edu.au!usenet
1993-04-10  1:03 Charles H. Sampson
1993-04-09 18:08 Dave Bashford
1993-04-09 14:06 Dan Rittersdorf
1993-04-08 22:28 Alex Blakemore
1993-04-08 19:03 Art Duncan
1993-04-08 16:18 Charles H. Sampson
1993-04-08 15:34 Christopher J. Henrich
1993-04-08 12:21 enterpoop.mit.edu!usc!cs.utexas.edu!mars.tsd.arlut.utexas.edu!gardner
1993-04-07 22:58 Mark Lundquist
1993-04-07 21:07 Ray Harwood -- Data Basix: (602)721-1988
1993-04-07 16:21 Charles H. Sampson
1993-04-07 12:42 Robert Firth
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox