Re: Linkage of namespace scope reference
* johnchx2@yahoo.com:
Alf P. Steinbach wrote:
Formally that's backwards, because for a reference it's the initializer
that determines whether the declaration is a definition, not the other
way around.
It has nothing to do with whether the name being declared is a
reference, it has to do with whether the name being declared is
explicitly declared extern.
Any declaration with the extern keyword is also a definition if and
only if an explicit initializer is present.
How is that different from what I wrote?
Declarations without the
extern keyword are always definitions. (I'm assuming we're just
talking about variable declarations; static data members, functions and
types follow...sigh...different rules.)
Well, a reference isn't a variable, so that's not what we're talking about.
I wonder if some confusion is caused by the assumption that keyword
extern has no effect other than to give the declared name external
linkage. This is a false assumption: it changes the meaning of the
declaration:
int i; // declares & defines i
extern int j; // declares but doesn't define j
Both i and j have external linkage. "extern" says both (1) give this
name external linkage and (2) treat this as a definition if and only if
I provide an explicit initializer.
The 'const' for something that a reference refers to is not a 'const'
for the reference itself.
The analogous case for non-reference would be a const pointer's linkage
being determined by the constness of what the pointer points to.
I think that is a mis-perception
What is a mis-perception, do you think?
that comes from thinking of references
as automatically dereferenced pointers, rather than as what the
standard says they are: pure aliases. Consider:
const int a = 0;
const int& b = a;
"a" names a const object. "b" also names a const object (as it
happens, the same one). They're alike. It's non-sensical to think of
"b" as naming "the reference", because no such object exists to name.
In order to declare 'b' as an 'extern' reference you need to be aware
that it's a reference, and declare it in other translation units as a
reference.
I don't think the standard is non-sensical here.
I think the only sensible way to think of 'b' is as a reference.
For the purpose of 'extern', which is what this tread is all about, it
won't do to treat 'b' as simply an alternate name for an object.
'extern const int b;' in some other translation unit does not refer to
'extern const int& b = a' in this one.
(Of course, in some situations, the implementation will use a pointer
"under the hood," e.g. for reference members. But that's an
implementation detail, irrelevant to the *concept* of references.)
Details matter, understanding the implementation matters, and yes,
concepts matter: none of it is irrelevant.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]