c++static-membersheader-only

How to have static data members in a header-only library?


What is the best way to have a static member in a non-templated library class, without placing the burden of defining the member on the class user?

Say I want to provide this class:

class i_want_a_static_member
{
    static expensive_resource static_resource_;

public:
    void foo()
    {
        static_resource_.bar();
    }
};

Then the user of the class must not forget to define the static member somewhere (as already answered many times):

// this must be done somewhere in a translation unit
expensive_resource i_want_a_static_member::static_resource_;

I do have an answer below, but it has some disadvantages. Are there better and/or more elegant solutions?


Solution

  • C++17 and above

    Use inline static variables for non-dynamic initialization:

    struct Foo
    {
        inline static int I = 0;
    };
    

    And use function local static variables otherwise:

    struct Foo
    {
        static std::string& Bar()
        {
            static std::string S = compute();
            return S;
        }
    };
    

    C++14 and below

    Use function local statics, as they are plain easier to use.

    If for some reason you really wish for a static data member, then you can use the template trick:

    template <typename T = void>
    struct Foo
    {
         static int I = 0; // inline initialization only for simple types.
    };
    
    template <typename T>
    int Foo<T>::I;
    

    On local statics

    For resources which require dynamic initialization, it is best to use a local static.

    The order in which file-scope or class-scope statics are dynamically initialized is undefined, in general, leading to the Static Initialization Order Fiasco when you try to read a uninitialized static as part of the initialization of another. Local static solve the issue by being initialized lazily, on first use.

    There is some slight overhead to using local statics, however. From C++11 onwards, the initialization is required to be thread-safe, which typically means that any access is gated by an atomic read and well-predicted branch.