Path: utzoo!attcan!uunet!zephyr.ens.tek.com!tekchips!ellis From: ellis@tekchips.LABS.TEK.COM (Cynthia Ellis) Newsgroups: comp.std.c++ Subject: Re: Blocks, scopes and declaration statements Summary: Possibly a scope definition bug in cfront2.0? (and 2.1?) Message-ID: <6933@tekchips.LABS.TEK.COM> Date: 16 Oct 90 21:36:26 GMT References: <77210008@hpclscu.HP.COM> Reply-To: ellis@tekchips.LABS.TEK.COM (Cynthia Ellis) Organization: Tektronix, Inc., Beaverton, OR. Lines: 54 In article <77210008@hpclscu.HP.COM> shankar@hpclscu.HP.COM (Shankar Unni) writes: >Does a declaration in the middle of a { } block start a new scope? A new >block? > >Consider the following example: > > void foo() > { > extern void bar(); // decl > int i; // decl > > i = 1; // statement > > extern void bar(int); // decl: overloaded with above bar()? > > bar(); // statement: legal? > } > >Is the second declaration of bar ("extern void bar(int)") considered an >overloaded variant of the parameterless bar(), or the start of a new scope >(so that it hides the parameterless bar())? Per E&S (section 6.3), a block is equivalent to a compound statement, which is a statement-list. A statement-list is then composed of a statement, or a statement-list followed by a statement. It is explicitly stated at end of the section that a declaration _is_ a statement (section 6.7). And, in section 6.0, E&S explicitly states that "... in C++ declarations need not be placed before statements in a block, but can be introduced where first needed". >Cfront 2.1 (and 2.0) apparently seems to make the latter interpretation, >and complains about the parameterless call to bar(). Somehow this must be some sort of scope definition bug in cfront2.0 (AT&T has some problem with our cfront2.1 upgrade paperwork, so I don't have 2.1 to test against yet). If you move the second extern void bar declaration so that it is before the "i = 1;" statement, the code compiles! So cfront2.0 must be tacitly assuming that the second bar declaration _does_ start a new block, which is (at least to me) in conflict with the excerpts of E&S section 6 quoted above. >The ARM (sections 7, 10.4, etc) is suitably obscure on this point. They do >mention that declarations hide other declarations of the same identifier in >"an outer block", but it's unclear as to how that is to be applied in the >above situation. By how I read E&S, this should all be in the same block, which means that the overriding argument should not apply here. Cynthia Ellis Tektronix, Inc. ellis@tekcrl.LABS.TEK.COM (503) 627-6680