"i" at line 2 is also a definition, which is visable to inner block
(i.e. line 3).
That's correct so far.
Therefore, I think line 3 is saying declare the "i" at
line 2 as external.
That would be logical, and it would be logical (IMHO) for the
above to be an error, since there are conflicting linkage
specifications. According to the standard, however, the "i" in
line 2 has no binding, so no other declaration can refer to it.
Thus, since line 3 can't refer to it, and line 1. isn't visible
at this point, line 3 declares still another i.
Thanks again. My email yesterday seemed to be deleted by google...
It's not an email, but a posting, and I also have the impression
that Google looses a few.
I'm still wondering why "i" at line2 is visible at line3, but there's
no binding for the "i" at line 2.
The "i" is visible because those are the rules of visibility in
C++ (and in most other scoped languages, I think). And the "i"
doesn't have linkage because that is also a rule of the
language.
Both of the rules, taken in isolation, make very good sense.
The problem is the interaction---since the "i" in 2 is visible,
I would normally expect that the declaration in 3 refers to it,
that it attempts to change the linkage, which isn't possible,
and so should be an error. But the standard says otherwise.
IMHO, it's not a real problem. There's never any reason to
declare an extern at local scope anyway---externs should always
be declared in header files, at namespace scope.
No binding means no linkage, is this correct?
No linkage is what I meant. No binding is a bit of sloppiness
on my part. (Binding is different than linkage, and isn't
relevant here.)
If so, is it completely useless to declare "i" at line 2? If
I have another line after line 2, but before the "{" above
line 3
static int i = 1 ; // 1.
void g()
{
std::cout << i ; // Outputs 1
int i = 2 ; // 2. Hides the static 1.
std::cout << i ; // Outputs 2
{
std::cout << i ; // Outputs 2
extern int i ; // 3. (Initialized to 3 elsewhere.
std::cout << i ; // Outputs 3
}
std::cout << i ; // Outputs 2
}
Although never for an extern, on very rare occasions, I've
introduced extra {} just to limit scope. In C++, this usually
occurs in order to ensure that the destructor is called at the
correct time, e.g.:
void
f()
{
// do something non critical...
{
scoped_lock l( someMutex ) ;
// locked region...
}
// unlocked here...
}
cout << i << endl;
then I think "i" at line 2 gets printed. Does it mean the "{" above
line 3 makes "i" at line 2 have no binding?
No. A variable declared at block scope (in a {...} in a
function) has no linkage by default; declaring it extern gives
it external linkage, unless there is a previous declaration
which has linkage and is visible.
The rules here are rather arbitrary, and I suspect that it's
another case of the committee just deciding that they had to
specify something, but it didn't matter much what. In good
code, you will not have any "extern" at block scope, so it
doesn't matter. But if you're writing a compiler, you have to
know what to do about it; a compiler has to work in a defined
manner even if fed "bad" code.
Whether you or I think that this is a good idea, or the way it
should be, is irrelevant. The above example is taken directly
from the standard.
I thought in general, objects declared at outer
block are always visible in the inner blocks, unless there's a re-
declaration/definition of it in the inner blocks, is this wrong?
(And if you aren't thoroughly confused yet, you should be.)
I am thoroughly confused, as you've correctly guessed... :(
Well, you seemed to want to know all of the details. And they
are confusing. I've written compilers in the past, and worked
with language standards for something like 20 years, and I still
have to go very, very slowly when attacking this in C++. (And
if you think that this is confusing, wait until you attack
function overload resolution, or name binding in templates.)
I indeed like to have a completely clear picture, though I see it's
impossible for me at the moment. I just hope to be more confident
when I write programs if I know which variables are visible at which
place and whether I'm referring to a variable that I intend to.
I understand totally, but be aware that even with over 15 years
experience in C++, there are aspects which remain hazy to me.
That doesn't necessarily stop me from writing correct code. In
this case, for example, the complication only involves cases
where you declare a variable extern at block scope. Don't do
that, and there's no problem. Avoid the same names for
different objects, and you don't have to worry about whether the
name refers to a file local static, or to a global. (I'm not
saying that the rules are intuitive, but they're generally clear
enough that one can learn them.)
--
James Kanze (GABI Software) email:james.ka...@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
least for now. :)