🚀 go-pugleaf

>In article <sjcDHqMKM.MBG@netcom.com>, Steven Correll <sjc@netcom.com> wrote:
>>This technique won't work in current compilers:
>>
>>	for (unsigned i = 0; ...; ...)
>>	  ...
>>	for (i = 0; ...; ...)
>>	  ...
>>
>>And this won't work in older ones:
>>
>>	for (unsigned i = 0; ...; ...)
>>	  ...
>>	for (unsigned i = 0; ...; ...)
>>	  ...
>>
>>Must portable programs do this?
>>
>>	for (unsigned i0 = 0; ...; ...)
>>	  ...
>>	for (unsigned i1 = 0; ...; ...)
>>	  ...

In article <DHzF5D.DKo@elt.com>, Randy Oxentenko <rdo@elt.com> wrote:
>It is, of course, still permissible in both cases to write this:
>
>	unsigned i;
>	for (i = 0; ...; ...)
>	  ...
>	for (i = 0; ...; ...)
>	  ...

To put an end to the long stream of replies suggesting this: Yes, I realize
one can use an uninitialized local variable. For that matter, one can use an
uninitialized _global_ variable. I assumed the entire point of permitting the
declaration to appear inside the "for" in the first place was to avoid
separating declaration from initialization.

Surely the short-term cost of the change is to make it cumbersome to
initialize a for-loop variable at the point of declaration (because either an
old compiler or a new one is likely to complain, and the macro workaround is
not robust); and the long-term cost is to make it impossible in some cases
(because the value defined inside the loop needs to be referenced after the
loop has terminated). The short- and long-term advantage is to make the
semantics of "for" more consistent with the semantics of "if". De gustibus
non disputandum...
-- 
Steven Correll == PO Box 66625, Scotts Valley, CA 95067 == sjc@netcom.com


---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]