Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!qt.cs.utexas.edu!yale.edu!cmcl2!uupsi!sunic!liuida!ricwe
From: ricwe@ida.liu.se (Rickard Westman)
Newsgroups: adsp.sw,comp.sys.amiga.programmer
Subject: Re: Major problem with Comeau C++ (and with old Lattice C++), Part 1
Keywords: Comeau C++ 2.1, Lattice C++, static class members
Message-ID: <1991Jun28.202630.6621@ida.liu.se>
Date: 28 Jun 91 20:26:30 GMT
References: <195cf3fd.ARN3850@moria.UUCP>
Sender: news@ida.liu.se
Organization: CIS Dept, Univ of Linkoping, Sweden
Lines: 45

bojsen@moria.UUCP (Per Bojsen) writes:

>I have found a serious problem with the AT&T cfront Comeau C++ is based on!
>This problem is associated with static members of classes, and thus affects
>usage of the iostream library (when including iostream.h).

>Consider a class definition:

>        class Object
>        {
>        public:
>          Object() { ObjectCount++; }
>          ~Object() { ObjectCount--; }

>        private:
>          static int ObjectCount;
>        };

>All objects of class Object share the ObjectCount member.  How can this
>behavior be represented in a C program (after all, cfront translates the
>C++ source to C)?  By defining an external variable of type int to hold
>the value of Object::ObjectCount.  This is precisely the source of the
>problem.  Every module that uses (read: defines objects of) class Object
>will need to reference this external variable.  But it needs to be
>*defined* somewhere.

Yes, and *you* need to do that, yourself.  Declare ObjectCount
globally in all files that uses the Object class.  Use the 'extern'
keyword in all but one of these declarations.  

In 'The Annotated C++ Reference Manual' (Ellis & Stroustrup), the
practice of allowing the definition of a static class member to be
omitted is described as an anachronism.  It does not have to be
provided by a correct C++ implementation:

"The declaration of a static data member in its class declaration is
 *not* a definition.  A definition is required elsewhere; see also
 paragraph 18.3"  (paragraph 18.3 describes anachronisms)

Clearly, Cfront implements this anachronism, but in a way that doesn't
work well with SAS/Lattice C.  You might just as well consider this
'feature' unsupported and adhere to the current language definition.

--
Rickard Westman, University of Linkoping, Sweden        ricwe@ida.liu.se