Path: utzoo!mnetor!uunet!husc6!mit-eddie!uw-beaver!fluke!ssc-vax!lee
From: lee@ssc-vax.UUCP (Lee Carver)
Newsgroups: comp.lang.misc
Subject: Re: FOR loops
Message-ID: <1028@ssc-bee.ssc-vax.UUCP>
Date: 17 Mar 88 17:36:55 GMT
References: <2827@enea.se> <1557@pasteur.Berkeley.Edu> <2853@enea.se>
Organization: Boeing Aerospace Corp., Seattle WA
Lines: 43
Summary: or ... package as a procedure

<>

Hope I didn't change the meaning of the parties prior discussion,
but in the following problem, why not package the loop as a
procedure/subroutine/function.  Clearly, it is being used to perform
an atomic action anyway.

Wayne A. Christopher (faustus@ic.Berkeley.EDU) writes:
>In article <2827@enea.se>, sommar@enea.se (Erland Sommarskog) writes:
>> ... Ada as I see it have
>> the perfect solution: The loop variable is declared in the FOR-
>> statement, and is thus not accessible afterwards.
>
>Here's the problem with that construct:  I often write
>	for (i = 0; i < max; i++)
>		if (something)
>			break;
>	if (i == max)
>          ...
> >If the loop variable is inaccessible outside of the loop there's
> >no way to tell how it terminated, except by using an extra flag,
> >which is ugly.

Here's the way I do it by better packaging:

int findSomething ( max )
int max;
{  int i;

   for (i = 0; i < max; i++)
      if (something) return i;

   /* not found */
   return max;
   }

No extra flag, some call overhead, and a re-usable commponent.  What
could be better (besides no call overhead :-)?

On a similar vein, one occasionally sees calls for new control
structures to supports some really baroque nesting of if statements.
What every happened to packaging the embedded if conditions as
subroutines?