Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!gatech!hubcap!ncrcae!ncrlnk!uunet!mcvax!ukc!dcl-cs!aber-cs!pcg
From: pcg@aber-cs.UUCP (Piercarlo Grandi)
Newsgroups: comp.lang.c++
Subject: Re: Static data members in C++ classes
Message-ID: <424@aber-cs.UUCP>
Date: 17 Dec 88 21:45:33 GMT
Reply-To: pcg@cs.aber.ac.uk (Piercarlo Grandi)
Distribution: eunet,world
Organization: CS Dept., University College of Wales, Aberystwyth, UK
	(Disclaimer: my statements are purely personal)
Lines: 53

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)