Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!devnull!kelley@mpd.tandem.com
From: kelley@mpd.tandem.com (Michael Kelley)
Newsgroups: comp.lang.c++
Subject: Re: Static member definition vs. declaration?
Message-ID: <186@devnull.mpd.tandem.com>
Date: 18 Apr 91 15:02:00 GMT
References: <1848@dinl.mmc.UUCP>
Sender: news@devnull.mpd.tandem.com
Lines: 37

In article <1848@dinl.mmc.UUCP>, noren@dinl.uucp (Charles Noren) writes:
> We have a debate in our group.  When you declare a static
> member, such as:
> 
>    class X {static int myVar;};
> 
> Do you need to make a definition elsewhere,
> 
>    int X::myVar;
> 
> I claim you do (and of course you want to initialize it
> at the same time).  Others in my group say you don't and
> offer proof that our 2.0 and 2.1 Cfront compilers do fine
> without the "int X::myVar" statement.  We all are aware
> of the holy writ (ARM) on page 179 and 405, but we vary
> on our interpretation of it.  I claim our compilers permit
> an anachronism, the others think not.
> 

Static members of fundamental types, or of a class with no constructor,
needn't be defined by the programmer.  Cfront 2.0 simply lays down a
definition for these critters, and lets the linker resolve them all
to the same address.  It can't be done for objects with constructors,
however, because it would be incorrect for all modules which "see" 
the static member to reinitialize it. I think not *having* to make
the definition in some cases has been rightly deemed an anachronism,
if for no other reason than you, I, and others having to ask
"do we or don't we?".  It's also prone to cause problems because
the default definitions will be zeroed out, which may not make any
sense.  I imagine that in future (2.2+?) releases, you will get link
errors on all static members not explicitly defined, and not just
those with constructors like you do now.

Mike Kelley
Tandem Computers, Austin, TX
kelley@mpd.tandem.com
(512) 244-8830 / Fax (512) 244-8247