schmidt@glacier.ics.uci.edu (Doug Schmidt) (12/13/88)
Hi,
I realize the following point has been raised here before, but I'm
still not entirely sure of the official party line. Simply put, which
sections of the following example are legal C++?
----------------------------------------
class foo {
private:
static int foobar; // Is this correct? My guess is yes.
public:
foo ( int i ) { foobar = i; }
};
class bar {
public:
static const int k = 10; // Is this correct? My guess is yes.
static foo i = 9; // Is this correct? My guess is no!
static foo j; // Is this correct? My guess is no!
bar ( ): j( 10 ) { ; }
};
----------------------------------------
On page 275 of the 1986 reference manual it states that:
``No initializer can be specified for a static member, and it cannot
be of a class with a constructor.''
The wording of the second part in the preceding sentence had mislead
me, and others, to believe that the first use of static in class foo (
i.e., static int foobar ) was incorrect. However, I no longer believe
that is true, since it appears that this sentence actually refers to
the latter part of class bar above, with static foo j being a primary
example of the proscription quoted from the manual.
**************************************************
Am I safe and correct in making these assumptions?
**************************************************
Finally, CC 1.2.1 gives the following diagnostics for the above program:
----------------------------------------
CC foo.C:
"foo.C", line 18: sorry, not implemented: static member bar::i
with initializer
"foo.C", line 18: sorry, not implemented: static member bar::i of class foo
with constructor
"foo.C", line 18: sorry, not implemented: static member bar::j of class foo
with constructor
"foo.C", line 18: sorry, not implemented: member initializer for static bar::j
4 errors
----------------------------------------
Since the error message wording is ``sorry, not implemented'' rather
than ``error, illegal construct'' does this imply that these features
are likely to appear in subsequent versions of the compiler? For
example, how does CC 2.0 handle the test case presented above?
Thanks for your help.
Doug Schmidt
P.S. What this newsgroup needs are more participants like Chris Torek
and Henry Spencer in comp.lang.c, who always seem to have concise and
thoughtful answers to the most wonderfully obscure questions ;-).
--
schmidt@ics.uci.edu (ARPA) | Per me si va nella citta' dolente.
| Per me si va nell'eterno dolore.
| Per me si va tra la perduta gente.
| Lasciate ogni speranza o voi ch'entrate.pcg@aber-cs.UUCP (Piercarlo Grandi) (12/18/88)
In article <1449@paris.ics.uci.edu> Doug Schmidt <schmidt@glacier.ics.uci.edu> writes:
# [ .... some examples of using static members of a class .... ]
#
# Since the error message wording is ``sorry, not implemented'' rather
# than ``error, illegal construct'' does this imply that these features
# are likely to appear in subsequent versions of the compiler? For
# example, how does CC 2.0 handle the test case presented above?
I don't know about CC 2.0, but g++ complains only on the line
# static foo j; // Is this correct? My guess is no!
to the effect that there is no default initializer for class foo.
This strikes me as eminently reasonable; static class members are handled as
though they were normal global entities, but as they belong a class scope
they must be accessed as either ptr->name or class::name, just like class
procedures. Also, both static class variables and class procedures do not
count towards the sizeof of an instance of a class.
Overall I think that the g++ approach makes more sense than that taken by
cfront 1.2.
I have another comment to make, but hang on...
# P.S. What this newsgroup needs are more participants like Chris Torek
# and Henry Spencer in comp.lang.c,
Not so easy... Unfortunately, the precious are few and usually very busy.
Michael Tiemann occasionally intervenes here, but I'd rather like him to
remain busy on g++ than on comp.lang.c++ :->...
# who always seem to have concise and thoughtful answers to the most
# wonderfully obscure questions ;-).
The comment I have delayed is that in C++ there often are no concise and
thoughtful answers to wonderfully obscure questions. Usually there are no
answers at all, because Bijarne Stroustrup did not bother with a lot of
detail, and in the process of evolving the language, he hasn't given much
time to clarification. To him C++ is still much of an experimental language.
As Michael Tiemann has written, if only somebody cared to define exactly what
the rules are in so many cases (especially visibility), many surprises would
be spared even to the wary, and many small incompatibilities between cfront
and g++ would not exist.
In general, I like the choices Tiemann has made to resolve ambiguities. I
like them better than those apparent from cfront 1.2 behaviour.
--
Piercarlo "Peter" Grandi INET: pcg@cs.aber.ac.uk
Sw.Eng. Group, Dept. of Computer Science UUCP: ...!mcvax!ukc!aber-cs!pcg
UCW, Penglais, Aberystwyth, WALES SY23 3BZ (UK)