Path: csiph.com!news.swapon.de!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: OT: improve this simple algorithm? Date: Thu, 28 Nov 2019 16:54:27 -0800 Organization: A noiseless patient Spider Lines: 90 Message-ID: <86a78f8pto.fsf@linuxsc.com> References: <87a790zn7z.fsf@bsb.me.uk> <_85zF.5075$II7.2317@fx17.iad> <8h8rse1ra0sel6snvfbrucvcbobn2okhg5@4ax.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="81b92e3fa8397acac1ab5cf195ff75cd"; logging-data="26130"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/kO9bl1gpsDGhXBIoJJFwhfh9RovZ68k4=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:zPGPY1gHVYZvtD5yI/QiwqUHEDQ= sha1:YXz9+zUBde7GBWp5iwINYGA5BVQ= Xref: csiph.com comp.lang.c:148207 Richard Damon writes: > On 11/15/19 9:46 AM, James Kuyper wrote: > >> On 11/14/19 4:08 PM, DFS wrote: >> >>> On 11/14/2019 2:03 PM, Barry Schwarz wrote: >> >> ... >> >>>> warning at all. Some even put the definition of i inside the for >>>> statement as in >>>> for (unsigned int i = 0; ... >>>> to insure the scope is limited to the loop. This will work even if >>>> there is an i defined before the for statement. The i in the for >>>> statement hides the i defined previously but only for the duration of >>>> the loop. >>> >>> Interesting. Works in nested for..loops too: >>> >>> >>> int i = 100, j = 200; >>> >>> for(int i = 0; i < 3; i++) { >>> for(int j = 0; j < 3; j++) { >>> printf("(%d %d) ",i,j); >>> } >>> } >>> >>> printf("\n%d %d\n",i,j); >>> >>> >>> (0 0) (0 1) (0 2) (1 0) (1 1) (1 2) (2 0) (2 1) (2 2) >>> 100 200 >>> >>> But... I see danger ahead. I'll probably not use that technique. >> >> I'm curious: what danger do you think you see? This feature was >> added specifically to reduce the danger of your loop variables >> interacting with code outside the loop. If you want your variables >> to interact with code outside the loop, declare them outside the >> loop, as has always been permitted - this feature does nothing to >> interfere with the old ways of doing things. > > As I remember, at one stage in the development of this feature, > the statement > > for(int i = 0; i < 3; i++){ > } > > was the equivalent of > > int i; > for(i = 0; i < 3; i++){ > } > > i.e., the defined variable existed after the loop. It was thought > that since the definition wasn't within the braces, the scope > shouldn't be limited to the braces. I am fairly sure this even > appeared in some of the draft standard documents. To set the record straight, this was never true for C. The draft where declarations-in-for's first appeared limited the scope of the declared variable(s) to the for statement (and its body), and not further. What you may have been thinking of was C++. Before C++ was first standardized, it did have for-declarations with the semantics you describe. It was defined that way in one of Stroustrup's books (second edition, roughly 1995, IIRC). This behavior was actually part of the official language, and programs made use of it. Last I checked there are still gcc options -ffor-scope and -fno-for-scope to allow getting the old semantics (and they apply only to C++). > In working with this, it was decided that this caused too many > issues, so they added a bit of complexity to the language by > moving the effective scope of the block to include the control > statement. Here again this statement holds for C++ but not for C. The original C++ semantics (ie, in draft standards) was a bit messy. The C semantics did change between the original introduction and the next draft, but has always been pretty clean, and was never of the "moving scopes around" variety that the early C++ standards (or drafts thereof) used. Thus we see that James Kuyper's statement "This feature was added specifically to reduce the danger of your loop variables interacting with code outside the loop" isn't really right. That is where the feature ended up, but it is not where it started.