Question

in a C++ program I need some helper constant objects that would be instantiated once, preferably when the program starts. Those objects would mostly be used within the same translation unit, so the simplest way to do this would be to make them static:

static const Helper h(params);

But then there is this static initialization order problem, so if Helper refers to some other statics (via params), this might lead to UB.

Another point is that I might eventually need to share this object between several units. If I just leave it static and put in a .h file, that would lead to multiple objects. I could avoid that by bothering with extern etc, but this can finally provoke the same initialization order issues (and not to say it looks very C-ish).

I thought about singletons, but that would be overkill due to the boilerplate code and inconvenient syntax (e.g. MySingleton::GetInstance().MyVar) – those objects are helpers, so they are supposed to simplify things, not to complicate them…

The same C++ FAQ mentions this option:

 Fred& x()
 {
   static Fred* ans = new Fred();
   return *ans;
 } 

Is this really used and considered a good thing? Should I do it this way, or would you suggest other alternatives? Thanks.

EDIT: I should have clarified why I actually need that helpers: they are very like normal constants, and could have been pre-calculated, but it is more convenient to do that at runtime. I would prefer to instantiate them before main, as it automatically resolves multi-threading issues (which local statics are not protected against in C++03). Also, as I said, they would often be limited to a translation unit, so it does not make sense to export them and initialize in main(). You can think of them as just constants but only known at runtime.

Answer 1

There are several possibilities for global state (whether mutable or not).

If you fear that you’ll have an initialization issue, then you should use the local static approach to create your instance.

Note that the clunky singleton design you present is not mandatory design:

class Singleton
{
public:
  static void DoSomething(int i)
  {
    Singleton& s = Instance();
    // do something with i
  }


private:
  Singleton() {}
  ~Singleton() {}

  static Singleton& Instance()
  {
    static Singleton S; // no dynamic allocation, it's unnecessary
    return S;
  }
};

// Invocation
Singleton::DoSomething(i);

Another design is somewhat similar, though I much prefer it because it makes transition to a non-global design much easier.

class Monoid
{
public:
  Monoid()
  {
    static State S;
    state = &s;
  }

  void doSomething(int i)
  {
    state->count += i;
  }

private:
  struct State
  {
    int count;
  };

  State* state;
};


// Use
Monoid m;
m.doSomething(1);

The net advantage here is that the “global-ness” of the state is hidden, it’s an implementation details that clients need not worry about. Very useful for caches.

Let us, will you, question the design:

• do you actually need to enforce the singularity ?
• do you actually need the object be built before main starts ?

Singularity is generally over-emphasized. C++0x will help here, but even then, technically enforcing singularity rather than relying on programmers to behave themselves can be very annoying… for example when writing tests: do you really want to unload/reload your program between each unit test just to change the configuration between each one ? Ugh. Much more simple to instantiate it once and have faith in your fellow programmers… or the functional tests 😉

The second question is more technical, than functional. If you do need the configuration before the entry point of your program, then you can simply read it when it starts.

It may sound naive, but there is actually one issue with computing during the library load: how do you handle errors ? If you throw, the library is not loaded. If you do not throw and go on, you are in an invalid state. Not so funny, is it ? Things are much simpler once the real work has begun, because you can use the regular control-flow logic.

And if you think about testing whether the state is valid or not… why not simply building everything at the point where you’d test ?

Finally, the very issue with global is the hidden dependencies that are introduced. It’s much better when dependencies are implicit to reason about the flow of execution, or the impacts of a refactoring.

---

EDIT:

Regarding initialization order issues: objects within a single translation unit are guaranteed to be initialized in the order they are defined.

Therefore, the following code is valid according to the standard:

static int foo() { return std::numeric_limits<int>::max() / 2; }
static int bar(int c) { return c*2; }

static int const x = foo();
static int const y = bar(x);

The initialization order is only an issue when referencing constants / variables defined in another translation unit. As such, static objects can naturally be expressed without issues as long as they only refer to static objects within the same translation unit.

Regarding the space issue: the as-if rule can do wonders here. Informally the as-if rule means that you specify a behavior and leave it up to the compiler/linker/runtime to provide it, without a care in the world for how it is provided. This is what actually enables optimizations.

Therefore, if the compiler chain can infer that the address of a constant is never taken, it may elide the constant altogether. If it can infer that several constants will always be equal, and once again that their address are never inspected, it may merge them together.