Re: and then... (a curiosity)

[Vinzent Hoefler <nntp-2008-08@t-domaingrabbing.de>]

On Tue, 02 Sep 2008 16:50:34 -0400, Robert A Duff wrote:

> Ray Blaak <rAYblaaK@STRIPCAPStelus.net> writes:
> 
>> Martin Krischik <krischik@users.sourceforge.net> writes:
>>> When I was at Polytechnic first language was PL/1, second Pascal and
>>> therefore methodology was different. i.E. Don't rely on the execution
>>> order of boolean expressing.
>>
>> This I also agree with, although I admit being used to the short circuit &&
>> forms in the C-like languages.
>>
>> But my point is about having the source code be clearer when both
>> operands are required to be evaluated, especially when this is a
>> possibility:
> 
> It seems to me that two cases come up in practise, for "A and [then] B".
> Either I don't care which gets evaluated first, and don't care whether
> or not both get evaluated, because there are no important side effects
> (that's "A and B"), or I care about order (that's "A and then B").
> 
> I never see cases where it is important that A and B both be evaluated.
> 
> Counterexamples, please?  ;-)  Realistic ones, I mean.

Hmm. Digging in *really* old (Turbo-Pascal) sourcecode, I found an old map
editor:

Example #1:

-- 8< --
    {$IFOPT B+} {$DEFINE OPTB} {$B-} {$ENDIF}
    for i := 0 to TESTFUNCS - 1 do
      b := b and MapTest[i](Contents);
    {$IFDEF OPTB} {$UNDEF OPTB} {$B+} {$ENDIF}
-- 8< --

MapTest is a list of procedures I wanted to execute to check the validity
of an edited map prior to exporting it.

#2:

-- 8< --
      {$IFOPT B-} {$DEFINE OPTB} {$B+} {$ENDIF}
      repeat
        P := Message (Desktop, evBroadCast, cmClose, @C);
      until ((P = NIL) or (C = cmCancel));
      {$IFDEF OPTB} {$UNDEF OPTB} {$B-} {$ENDIF}
-- 8< --

Not quite sure, why I did it here. Seems, more than 10 years ago, I lacked
commenting properly. ;)

Finally #3 (and one of those MapTest functions mentioned above, so one can
see why I did it):

-- 8< --
{$A+,B-,D+,E-,F+,G+,I+,L+,N-,O+,R-,S-,V+,X-}
{    ^^ important!!!}

[...]

function AtLeastOneActor;
var
  b : boolean;
  i,
  j : byte;

begin
  b := False;

  for i := 1 to 62 do
  for j := 1 to 62 do
    b := b or (X.mpObj_Data[i][j].odActors <> 0);

  AtLeastOneActor := b or SaveMsgBox (NOACTOR);
end; {AtLeastOneActor}
-- 8< --

(Uh, bad code, literal constants...)

So, maybe I would generally write it different today, but for an example,
it is as real as it gets.


Vinzent.