Re: Linkage of namespace scope reference
Alf P. Steinbach wrote:
* kanze:
"Alf P. Steinbach" wrote:
* If a reference has external linkage because it's
explicitly declared 'extern', the initializer can be
omitted (?8.5.3/3, "The initializer can be omitted
only ... where the extern specifier is explicitly
used").
* If, OTOH., a reference has external linkage because it
doesn't refer to const and hasn't been declared
'static', the initializer cannot be omitted.
So the requirement to initialize locally hinges not on the
effective linkage of the reference, i.e. on whether the
intent is to initialize it once, in some translation unit,
but on precisely how it acquired external linkage, which,
as I see it, doesn't matter at all wrt. safety or
correctness or any sound criterion for a local
initialization requirement, and is inconsistent with the
requirements for other types.
Not really. You're missing another important point: which
declarations are in fact definitions. A reference at
namespace scope which is not declared extern (or a reference
with an initialization, even if it is declared extern) is a
definition. There can only be one definition of the
reference in the entire program (or else you have undefined
behavior -- and typically, an error from the linker), and
that definition must have an initialization clause.
I don't think I missed that point.
Then I misunderstood your point. The rule is "coherent": a
declaration of a reference must have an initializer if and only
if it is a definition. (In some cases, the presense or absense
of the initializer determines whether it is a definition.)
I don't think that the rules are as coherent as they could be,
but the incoherence doesn't directly concern the requirement to
have an initializer or not. In every case where the initializer
can be omitted, if it is omitted, the declaration is not a
definition.
That was my point. It's a peculiar, seemingly arbitrary
special case for references.
I'm afraid that I still don't see a special case. Exactly the
same rules apply to a const int: if the declaration is a
definition, then an initializer must be present. And the only
way a declaration of a const int is not a definition is if the
declaration declares external linkage:
int const i1 ; // error, initialization required.
extern int const i2 ; // no initialization required.
In the case of a reference, we have the issue that even
references that acquire their external linkage implicitly
require initialization:
int& ri ; // error, initialization required,
// because this is a definition.
If there is an incoherence, it is that const objects and
references to const implicitly have internal linkage, whereas
the same declaration without the const has external linkage.
But this incoherence affects both objects and references.
The way a not explicitly "extern" reference declaration is a
definition is similar to how a not explicitly "extern"
constant declaration is a definition. But the way such a
reference can have external linkage by default is different
from constants.
Sort of. But that's at least partially due to the fact that the
standard doesn't consider a reference an object, but rather
another name for an existing object.
At namespace scope, we have
T& r = o; // External linkage, definition because of type.
T* const p = &o; // Internal linkage, definition because of type.
One would expect, and I did originally expect, that when
initialization is required, internal linkage is implied, but
this special case breaks that expectation -- for no good
reason that I can see.
For the basic reason that initialization of a reference doesn't
mean at all the same thing that initialization of an object
does. The initialization of a reference doesn't "initialize"
anything in memory, because references don't have to live in
memory. It tells the compiler what the reference is an alias
for.
From the point of view of the standard, of course. I often
wonder if it wouldn't be clearer if the standard had taken the
approach that a reference is a constant, implicitly dereferenced
pointer, rather than to say that it is something entirely
different, but carefully defined so as to be compatible with a
constant, dereferenced pointer. But the fact remains that
formally, initialization of a reference isn't so much the
initialization of a value as telling the compiler what the
reference aliases. It's not what I would usually consider
initialization at all.
Perhaps the best approach is to view constants as the special
case.
They are.
Or, come to think of it, to view both references and constants
as special cases, which makes ordinary variables a third
special case, so that all we have is a collection of special
cases...
In sum, par for the course:-).
But I think that's really it. There's no exception concerning
references and initialization, but three sets of rules
concerning which declarations are also definitions, and the
linkage of the declared names, one for references, one for const
objects, and one for non-const objects. (Or maybe four sets:
references to const objects and references to non-const objects
have different rules.)
--
James Kanze GABI Software
Conseils en informatique orient9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S9mard, 78210 St.-Cyr-l'cole, France, +33 (0)1 30 23 00 34
---
[ 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 ]