Path: utzoo!attcan!uunet!samsung!usc!rutgers!uwvax!heurikon!ex.heurikon.com!daves From: daves@ex.heurikon.com (Dave Scidmore) Newsgroups: comp.lang.c++ Subject: Re: FORever Message-ID: <937@heurikon.heurikon.com> Date: 16 Oct 90 17:28:05 GMT References: <6303@drutx.ATT.COM> <1990Oct10.195031.5018@indetech.com> Sender: news@heurikon.heurikon.com Reply-To: daves@ex.heurikon.com (Dave Scidmore) Distribution: comp Organization: Heurikon Corporation, Madison, WI Lines: 79 In article <1990Sep27.150948.9109@sco.COM> ron@sco.COM (Ron Irvine) writes: ron> BEWARE there is a major problem with C++'s "for" statement. ron> ron> main() { ron> for (int i=10; i<13;) { ron> for (int i=0; i<3; ++i) ron> ; // stuff ron> ++i; ron> } ron> } ron> ... ron> This is a bad joke for a language that is designed for the 90's. ron> The scope of a variable in a "for-init-statement" MUST end ron> at the end of the "for" statement. Lets change the definition of ron> the language NOW before we inflict horrendous pain on C++ programmers. Response From: marc@dumbcat.sf.ca.us (Marco S Hyman) Marco> Marco> Do you really want to break all the existing code that does something like Marco> Marco> for (int i=10; i<13; ++i) { ^^^^^^^^ Marco> if (x[i] == magicValue) { Marco> break; Marco> } Marco> } Marco> if (i >= 13) { Marco> // we didn't find magicValue Marco> } Marco> Marco> Lots of C code uses this. I assume (which will probably get me into Marco> trouble) that C++ programmers will want to do the same thing. Marco> > Actually, since C code does *not* allow declarations in the middle of > a "for" statement, this adjustment does *not* seem to break any "old C > code". My assumption would be that he wished to say break existing C++ code and accidentaly wrote existing C code. > I am aware that current semantic rules (re: E&S and cfront) support > the odd behavior wherein variables declared in the for statement are > "exported" to the enclosing scope. From my view, this would appear to > be a "bug" in cfront that has grown to be gospel in E&S. Since this "bug", as you call it, also appears in "The C++ Programming Language" semantic rules, and since the language had been in use at AT&T for some time before either book was published I can only assume it was a carefully considered decision and not a bug. Faced with the same decision I have to admit that I would have made the same choice. To make the variable a part of the outer scope allows it to be used after the end of the "for" statement while restricting it to the inner scope only prevent problems where bad programming practices are used, i.e. multiple variables with the same name in different scopes. On top of this the variable actualy appears outside the curly braces which delimit the inner scope, making it intuitively obvious that it is not a part of that scope. If curly braces introduce a new scope, as the semantic rules for C++ state then the "for" loop variable must be part of the outer scope and not the inner one. > I personally don't think that any of the little quirks in C++ (this is > only one) can, in and of themselves individually, damage the language. It is poor form to use unnamed "quirks" as an argument. Give us examples. > I agree with Ron Irvine, and I would like to see the for statement > limit the scope of declared variables to its own "for statement > scope". I dissagree. I have had no problem dealing with this rule and understanding its consequences from the first time I read about it. I also would submit that the current scope rules provided by E&S are consistent and that the rule you are proposing is not. -- Dave Scidmore, Heurikon Corp. dave.scidmore@heurikon.com