Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!att!pacbell.com!ucsd!network.ucsd.edu!calmasd!wlp
From: wlp@calmasd.Prime.COM (Walter L. Peterson, Jr.)
Newsgroups: comp.lang.c++
Subject: Re: Initializing static area of classes....
Keywords: static members, external linkage
Message-ID: <2407@calmasd.Prime.COM>
Date: 12 Mar 91 17:07:54 GMT
Organization: ComputerVision, A Prime Company. San Diego R&D
Lines: 66


In article  <13174@helios.TAMU.EDU|> jeffw@sparc27.tamu.EDU (Jeffrey A Waller) writes:
|>I would only agree if this data area included static class members which required 
|>dynamic initialization.  Otherwise leave everything in the class:
|>
|>class Foo
|>{  private:
|>
|>      static int count;
|>      .
|>      .
|>      .
|>      void initialize_static_stuff();
|>
|>   public:
|>
|>       Foo()
|>       {  if(!count++) initialize_static_stuff();
|>          .
|>          .
|>          .
|>       }
|>};
|>
|>Obviously, there are restrictions, though it works with what I find to be the
|>most common sort of initialization -- calling malloc and/or new. 
|>



It is true that static data members that do not require dynamic initialization
do not need the technique from the ARM, however, they do not need this also 
dont, in general,  need this technique either.  They frequently can just be
initialized where they are declared in the class.

In any case there is one problem with the implementation shown above. That is
a problem with efficiency.  In the example above, the test of count will be
made every time an instance of Foo is created, even though it is only needed 
when the first instance is created. 

The example in my article, ( which was shamelessly cribbed from the ARM ) will
be executed exactly once upon the comming into scope of each translation unit
which included the header file.

If Foo is a class that might have many instances created, such as a 2D or 3D
point class in a CAD system, this efficiency issue can be significant.

Also, it is always possible to find specific solutions to specific problems
that are "better" for that particular problem than more general solutions.
The solution from the ARM which I wrote about is a very general solution, that
will work in virutally all cases.

Finally:  The exact technique used to hack arround this problem in C++ is not
and should not be the real issue. The real issue is that the current lack of 
definition of the order of initialization of externally linked objects is 
not an acceptable state of afairs and a proper solution to this problem must
be addressed by X3J16.




-- 
"Exploring the consensual hallucination of cyberspace"
 Walter L. Peterson, Jr.
 Internet   : wlp@calmasd.Prime.COM        CompuServe : 70441,3177
"The opinions expressed here are my own."