newbie: C++ static initializer (constructor vs bool)

Hi,

This is obviously a newbie question.  I know that constructors for
static class instances are invoked in different modules in
unpredictable order.  My question is whether this is true of static
boolean variables as well.  For example, in the following code, I'm
wondering if the Digest::Hash() function can be called safely from
other initializers, which would be true if the "inited" boolean is
guaranteed to be set to its initial value before any static
constructors are invoked in any modules.  If the same unpredictability
of static initializer order applies to booleans then this code is
unsafe.  Which is the case?

// Digest.h

class Digest {
     enum { RANGE = 1000 }; // 1000 precalculated values
     static bool       inited;       // set to false in Digest.cpp
     static int*        array;        // array of hash values created
by constructor (set to null in Digest.cpp)

     static int LCG (int v);       // slow computation of munged "v"

     static void Init ()
     {
          array = reinterpret_cast<int*>(malloc(sizeof(int)*RANGE));
          ... fill array with precalc values
          inited = true;
     }

     public:

     // ??? can Hash() be called in different module during
     // static C++ initializer time when inited is garbage true-like
value
     // and therefore array is a garbage pointer value, then Crash!

    static int Hash (int v)
    {
        if (!inited) Init();
        if ((unsigned int)v < (unsigned int)RANGE)
             return array[v];
        else
             return LCG(v);
    }
};


// Digest.cpp

bool Digest::inited = false;
int* Digest::array = 0;

int Digest::LCG (int v)
{
   ....
}


      [ See  http://www.**--****.com/ ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Your suspicion that booleans (and other built-in types) are initialised 
first is correct. In fact, any global or static POD member is just laid 
out in the executable you're loading directly, and no real 
initialisation is happening. That's the reason why you specify a value 
at definition for those types (as your comment says you did), but not 
for non-PODs.

So you're code is safe in that regard. Some unrelated comments:


1. Use new rather than malloc (malloc is C)

2. Use static_cast for this kind of cast. Use const_cast and 
dynamic_cast in other cases. Never use the legacy C-style cast you used 
below, and also never use reinterpret_cast unless you know exactly what 
you're doing.

So better is:

array = new int[RANGE];

Even better is to use a container so you don't deal with memory 
management yourself.

Then, since these are not built-in types, you have the problem of 
initialisation order again. Thus, I'd also suggest using function-scope 
statics, as these are guaranteed to be initialised in order of first use:

struct Digest
{
    Digest()
    {
       // init mArray here
    }

    int Hash(int v)
    {
       return mArray[v];
    }

    std::vector< int > mArray;
};

Digest const& getGlobalDigest()
{
    static Digest singleton;
    return singleton;
}

int main()
{
    int x = getGlobalDigest().Hash(42);
}

(untested)

Jens

      [ See  http://www.**--****.com/ ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

The type has nothing to do with it.  The difference is that
static initialization occurs before dynamic initialization.  For
initialization to be static, the initialized type must have a
trivial constructor (which is the case of all built-in types,
like boolean, and all POD structs), and the initialization must
be from a constant expression.  So:

    bool b1 = true ;            //  static
    bool b1 = f()  ;            //  dynamic


As long as the initialization is static, it will occur before
any line of code you write (including code used in dynamic
initialization) takes place.  Even before static initialization
(conceptually, at least---there's no way you can see the order)
is zero initialization.  Not a few initialization tricks are
based on this as well.





IMHO,
    new int[ RANGE ]
would seem more appropriate to allocate the memory.








Just a question, but is there any reason why you don't use the
standard singleton pattern here?


      [ See  http://www.**--****.com/ ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

I'm actually not using malloc!  I'm having to use memory allocated by
java.nio.ByteBuffer in the JVM which I slurp into a SuperHeap data
structure of my own managing.  The second issue is this is used to
build a faster intset than a redblack tree, based on random digest of
key.  This intset is a bottleneck of the whole program, and I want my
Digest::Hash to be 100% inlined except when the check of the init
boolean returns false.  That's why I don't use the singleton pattern.
Its a few extra instructions, as well as a JSR.

Thanks for your tip on the zero value that happens before the non-zero
value.  I can't imagine what tricks could be done with that!


      [ See  http://www.**--****.com/ ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]