Avoid static objects

Avoid modifying static data because the page it is on will no longer be shared. This is not an absolute rule; it's all right to have modifiable static data or static objects with constructors in a library, as discussed next.

The best way to avoid modifying static data is to not have it in a shared library. This includes static objects with constructors, because the constructors run after library initialization and modify the storage for the object, resulting in a separate copy for each task (plus anything else on the same page). Static objects or struct's initialized by C-style initializers can be shared between all tasks.

If you need static data that is modifiable or is an object, allocate it on demand. For example, rather than having a static array, have a static pointer, and allocate the array the first time it is needed. The same is true for objects with constructors; allocate them as needed. One useful trick is to place static objects inside functions rather than at file scope; then they are initialized the first time the function is called. This works for heap storage as well:

      void TFoo::Bar()
  {
      static TBaz *gWhatever = new TBaz();
      ...
  }
The allocation only happens once. Of course, this is useful only inside one function, but that function can be of the GetWhatever() variety and can be a static member. Destructors for static local objects are called at static destructor time, but with a pointer (as in the example) there is no destructor, so the object is not destroyed automatically. Remember too that there are concurrency considerations for all static variables, including those declared inside a function--such as when more than one thread calls TFoo::Bar().

Modifiable statics in a library

You can have modifiable static data or static objects with constructors in a library. Just remember that they take space, and if they aren't used the space is wasted. If the objects are small and few, that's not a problem compared to the added complexity of allocating them on demand. If they're used frequently, allocating them on demand can take more space for the allocation code. Look at your link map to discover how much space your static objects require. Then look at each static object in your library and ask yourself which ones are used infrequently and how big are they?

It's not a good idea to export static objects with constructors from the interface of your library, because you can run into the infamous order of execution of constructors of static objects problem described in "Static object constructors" on page 74 (for a full discussion and ideas on how to work around it, see the next section, "Consider alternatives to temporary objects"). If you try to use an exported static object from your own static object constructor, you have a 50-50 chance of hitting the problem. Thus, it's best to use a different technique. Static objects that don't have constructors or destructors do not have this problem.

[Contents] [Previous] [Next]
Click the icon to mail questions or corrections about this material to Taligent personnel.
Copyright©1995 Taligent,Inc. All rights reserved.

Generated with WebMaker