Path: utzoo!attcan!uunet!microsoft!jimad
From: jimad@microsoft.UUCP (Jim ADCOCK)
Newsgroups: comp.std.c++
Subject: Re: Blocks, scopes and declaration statements
Message-ID: <58350@microsoft.UUCP>
Date: 18 Oct 90 18:16:44 GMT
References: <77210008@hpclscu.HP.COM>
Reply-To: jimad@microsoft.UUCP (Jim ADCOCK)
Organization: Microsoft Corp., Redmond WA
Lines: 55

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 your example, slightly rewritten:

void foo()
{
    extern void bar();
    // int i; i=5;
    extern void bar(int);
    bar();
    bar(5);
}

Introduce the int i line, and it fails to compile on the compiler mentioned.

|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())?
|
|Cfront 2.1 (and 2.0) apparently seems to make the latter interpretation,
|and complains about the parameterless call to bar().

Without the intervening "int i" line, it compiles.  So, if anything,
the compiler is interpreting the "int i" line as the start of the new
scope.  But even if it *is* the start of a new scope, shouldn't both
bars still be accessible?

|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.

Even if a new scope is being introduced, I still would not expect the
"outer" bar to be hidden by the "inner" bar with a different parameter
list.  And, I think introducing a new declaration or definition or
executable statement should not introduce a new "hidden" scope.  To
do so defeats the idea that in C++ you should be able to intoduce a new
variable where first used -- because to do so then introduces a hidden
scope that can cause the meaning of some variables already written to 
change.  Example: consider editing a large existing foo function having
within it the same bar declarations and usages as above.  In modifying
the existing function you introduce the "int i; i=5" statement in the
middle of the routine.  All of a sudden distant parts of foo fail to 
compile.

So I believe introducing a new variable in a routine does not start a new
scope, and both bar() and bar(int) should remain accessible even if there
were an intervening new scope introduced.

I'd be tempted to call this a compiler limitation, rather than a language
definition issue.

[standard disclaimer]