11.5. Statics Coda

When you boil it all down, the problems of statics are ordering, identity, and timing. It's not hard to imagine how the language came to be vulnerable to these three issues. Ordering is really only an issue when you have several global objects which accrete interdependencies: this would not have been an issue in the early days of their use, since there simply would not have been many at all, just the odd cout and cin. Identity is really only a problem when you have multiple link units within an executable; dynamic linking, while not exactly a new technology, is not so old as to have been of prime importance during the original design of C++. Timing is only an issue in multithreaded scenarios; as with dynamic libraries, multithreading is something that has become prevalent after the original designs of C++.

That's not to say that all these problems could have been avoided had the original designers of the language only had sufficient foresight or a time machine. Later languages still fail to address these issues convincingly: sometimes by disallowing the problematic construct—requiring all objects be heap based; sometimes not addressing them any better (and often worse) than C++. What new language is efficient, and yet immune to threading issues?

So, I'll trot out my well-worn advice. The only true solution is to be aware of the issues, and use the techniques for obviating, or at least ameliorating, the problems where appropriate. Most of these techniques are conceptually very simple, even if the implementation of them can be tedious (i.e., API-based singletons).

Before we leave this chapter, don't you think it's kind of nice that the answers to most of the problems of the various uses of static rely on the static keyword itself? And then, of course, there's the old spin mutex....