Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!jarthur!ucivax!orion.oac.uci.edu!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....
Message-ID: <2390@calmasd.Prime.COM>
Date: 7 Mar 91 16:11:37 GMT
References: <1991Mar4.224519.6434@bronze.ucs.indiana.edu>
Organization: ComputerVision, A Prime Company. San Diego R&D
Lines: 83

In article <1991Mar4.224519.6434@bronze.ucs.indiana.edu> nsundare@copper.ucs.indiana.edu (Neelakantan Sundaresan) writes:
>
>I am trying to solve the problem of initializing the static(shared) data
>area of a class type. Basically I would like this initializtion and any
>other house keeping stuff done, when the first object instance of that
>class is 'construct'ed. Is there a neat way to achieve this?
>

There is no "neat" way to do this. There is, however, "A" way to do
this. What you need to do is create yet another class, not a special
constuctor.  If your class is called Foo, lets call this new class
Foo_Starter:

    // declare clas Foo here

    class Foo {
      static whatever;
    };


    class Foo_Starter {
      static count;
    public:
      Foo_Starter() {
        if (count++ == 0) {
          whatever = 33;   // initialize Foo's static data members
        }
      }

      ~Foo_Starter() {
        if (--count ==0) {
          // clean up Foo's statics ( if necessary )
        }
      }
    };

    static Foo_Starter startfoo;


Put these declarations and definitions in the same header file. When
that header file's code is encountered for the first time during
execution, the static instance of Foo_Starter will be constructed. The
static data member count in Foo_Starter will have been initialized to
zero.  By the language definition of C++ statics, unlike all other
type of objects, ARE initialized to zero.  The constructor will test
count before incrementing it and if it is zero, will initialize the
statics for your class Foo. Since the value of count is now
incremented, any further encounters with this header code will not
cause re-initialization of Foo's statics.  The destructor can do any
clean up that might be necessary.  

It is important to note that the point in the Foo_Starter constructor
where it initializes the static is NOT where the static is defined.
The static MUST still be defined in some file that will occur once and
ONLY once in a program; that is to say in a .c file.  So, if this
header file is called Foo.h and Foo's member functions are defined in
a file called Foo.c, you will need to define the statics at file-scope
level in Foo.c.

Please note that this "fix" prevents you from declaring either an
extern or static to be a const or a *const since the initialization
will not be able to take place at the same point as definition.

All of this folderol is necessary because C++ does not specify any
order to the initialization of objects with external linkage. 
Some hack (er.. trick,   er.... technique) like this is absolutely
essential if you are going to declare any instances of Foo at
file-scope level and if the construction of those instances relies
on the existance of some meaningfull data existing in the statics.

Refer to section 3.4 of the ARM for a more detailed
explaination/excuse of this stuff.

It is to be hoped that X3J16 will take some positive action with
regard to the order of initialization of object with external linkage
so that hacks like this will not be needed in the future.


-- 
"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."