Xref: utzoo comp.lang.c++:8282 gnu.g++.bug:1989
Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!mailrus!umich!samsung!usc!apple!portal!cup.portal.com!wmmiller
From: wmmiller@cup.portal.com (William Michael Miller)
Newsgroups: comp.lang.c++,gnu.g++.bug
Subject: Re: Linkage of static members
Message-ID: <31285@cup.portal.com>
Date: 30 Jun 90 17:02:18 GMT
References: <10460@batcomputer.tn.cornell.edu><PCG.90Jun26213003@rupert.cs.
 aber.ac.uk> <274@taumet.com><31208@cup.portal.com>
  <PCG.90Jun29143913@odin.cs.aber.ac.uk>
Organization: The Portal System (TM)
Lines: 42

pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:
> Ahh, but consts have internal linkage unless _explicitly_ specified
> extern. Which rule prevails?

There's no conflict.  The rule to which you refer states: "A name of file
scope that is explicitly declared const and not explicitly declared extern
is local to its file" (ARM 3.3).  Const class members do not have file
scope.

> This would be wonderful... But where is it said that a storage class
> specifier is illegal in the definition of a static class member?

It's not as explicit as one might like, and I expect that X3J16 may want to
add some wording to the description here.  It is implicit, however, in a
comparison of sections 3.3, 7.1.1, and 9.4 of the ARM.  3.3 and 9.4 say that
a name declared in a class as static has external linkage.  3.3 and 7.1.1
say that a name at file scope specified static has internal linkage.  7.1.1
says that all linkage specifications for a name must agree and gives
examples where it is illegal to specify a name as static once it has already
received, even implicitly, external linkage.

(Rereading these two comments back-to-back make it evident that the
terminology in the ARM needs to be tightened up: const class members don't
have file scope because they're declared inside a class; however, static
class members *must* be defined at file scope.  Perhaps concepts like
"introducing declaration" and "defining declaration" should be used.)

> Note that I have my own ideas about all this mess; just like all the
> confusion about member pointers is caused by the useless notion of
> member function, and that around MI is caused by the erroneous notion of
> prefixing, all the trouble here is caused by the lack of a notion of
> class objec, or the unresolved tension between class-as-module and
> class-as-object-template.

You seem to find a lot of problems that don't particularly seem like
problems to me.  C++ is clearly not the most elegant, concise, and formally
pure language conceivable, but I don't think it's as fundamentally flawed as
you do.

------------------------------------------------------------------------------
William M. Miller, Glockenspiel, Inc.; P. O. Box 366, Sudbury, MA 01776-0003
wmmiller@cup.portal.com         BIX: wmiller            CI$: 72105,1744