pkglog
KO

C++ static Members: Static Data & Static Functions

By · · 11 min read · Updated Beginner tutorial

Key takeaways

Class static members shared by all instances: declaration vs definition, ODR, thread safety, singletons, factories, and C++17 inline static in headers, plus the link errors, data races and initialization-order bugs they cause.

What Are Static Members?

Normally, each object of a class has its own copy of member variables. A static member variable is shared by all objects of the class — there is exactly one copy regardless of how many instances exist:

#include <iostream>

class Connection {
    static int count_;  // shared by all Connection objects
    int id_;

public:
    Connection() : id_(++count_) {
        std::cout << "Connection " << id_ << " opened (total: " << count_ << ")\n";
    }
    ~Connection() {
        std::cout << "Connection " << id_ << " closed (total: " << --count_ << ")\n";
    }

    static int activeCount() { return count_; }  // static function
};

// Definition outside the class — required (pre-C++17)
int Connection::count_ = 0;

int main() {
    Connection c1;  // Connection 1 opened (total: 1)
    Connection c2;  // Connection 2 opened (total: 2)
    {
        Connection c3;  // Connection 3 opened (total: 3)
    }                   // Connection 3 closed (total: 2)
    std::cout << "Active: " << Connection::activeCount() << '\n';  // Active: 2
}

Declaration vs Definition

Static data members must be declared in the class but defined outside (in exactly one .cpp file). This is the One Definition Rule (ODR):

// header: connection.h
class Connection {
    static int count_;        // declaration — says the member exists
    static const int max_;   // declaration

public:
    static int activeCount();
};

// source: connection.cpp
int Connection::count_ = 0;          // definition — allocates storage
const int Connection::max_ = 100;    // definition

If you put the definition in the header and include the header in multiple .cpp files, the linker will report a “multiple definition” error.

C++17: inline static

C++17 introduced inline static to allow definitions directly in the class:

// header: config.h — works in C++17 and later
class Config {
public:
    inline static int maxConnections = 100;
    inline static std::string serverName = "localhost";
    static constexpr int version = 3;  // constexpr static is implicitly inline
};

// No separate .cpp definition needed

The inline static syntax makes the in-class definition the one official definition — multiple .cpp files that include the header all use the same instance.

The pre-C++17 rules produced one especially confusing linker error. A static const int max_ = 100; initialized inside the class could be used as a value without any out-of-class definition, so code compiled and linked for months, until someone wrote std::max(x, Connection::max_). std::max takes its arguments by const&, binding a reference needs an address, and the linker then failed with undefined reference to 'Connection::max_'. Nothing about the line looks wrong. In C++17, static constexpr members are implicitly inline and this error disappears; with plain static const in older code, add the out-of-class definition (without repeating the initializer).

Forgetting the .cpp definition of a non-inline static member produces the same kind of error: the code compiles, because the declaration is enough for the compiler, and fails at link time with undefined reference (GCC/Clang) or LNK2001: unresolved external symbol (MSVC).

Static Member Functions

Static member functions belong to the class, not any instance. They have no this pointer:

#include <string>
#include <iostream>

class Logger {
    std::string prefix_;
    static int logCount_;

public:
    explicit Logger(std::string prefix) : prefix_(std::move(prefix)) {}

    // Non-static: operates on an instance
    void log(const std::string& msg) {
        ++logCount_;
        std::cout << '[' << prefix_ << "] " << msg << '\n';
    }

    // Static: no instance needed
    static int totalLogs() { return logCount_; }
    static void resetCount() { logCount_ = 0; }
};

int Logger::logCount_ = 0;

int main() {
    Logger app("APP"), db("DB");

    app.log("Started");      // [APP] Started
    db.log("Connected");     // [DB] Connected
    app.log("Processing");   // [APP] Processing

    // Call static function on the class (no object required)
    std::cout << "Total logs: " << Logger::totalLogs() << '\n';  // 3
}

Static member functions:

  • Can be called as ClassName::function() without an object
  • Can also be called on an instance: obj.staticFunction() (but this is misleading — no this inside)
  • Can access private static members
  • Cannot access non-static members (no this)

Because there is no hidden this parameter, &Logger::totalLogs is an ordinary function pointer, int (*)(), not a pointer-to-member. That is why static member functions are the usual bridge to C APIs that take callbacks, such as pthread_create or a GUI toolkit’s C interface: the static function receives the void* user-data argument, casts it back to the object, and calls a normal member function. A static member function also cannot be const or virtual, since both qualifiers are about the object it is called on.

Singleton Pattern

A singleton ensures only one instance exists. The Meyers singleton (function-local static) is the cleanest modern form:

class AppConfig {
    std::string host_;
    int port_;

    // Private constructor — cannot create directly
    AppConfig() : host_("localhost"), port_(8080) {}

public:
    // Meyers singleton — thread-safe since C++11
    static AppConfig& instance() {
        static AppConfig inst;  // created once on first call
        return inst;
    }

    // Non-copyable
    AppConfig(const AppConfig&) = delete;
    AppConfig& operator=(const AppConfig&) = delete;

    const std::string& host() const { return host_; }
    int port() const { return port_; }

    void setPort(int p) { port_ = p; }
};

int main() {
    AppConfig::instance().setPort(9090);

    // Multiple calls return the same instance
    std::cout << AppConfig::instance().host() << ':';
    std::cout << AppConfig::instance().port() << '\n';  // localhost:9090
}

The function-local static is guaranteed to be initialized exactly once, and the initialization is thread-safe in C++11 and later.

What this guarantee doesn’t cover, and where I’ve seen it bite people: destruction order. Function-local statics are destroyed in the reverse of their initialization order, at program exit — so if one singleton’s destructor tries to use another singleton that happened to be constructed later (and is therefore destroyed earlier), you can end up calling a method on an object whose destructor has already run. This “static destruction order fiasco” is the mirror image of the initialization-order problem described below, and it’s a real reason to keep singletons as independent of each other as possible, or to avoid doing meaningful work in their destructors at all — a singleton that just releases memory it owns is safe; one that logs to another singleton on the way out is a landmine.

Static Factory Methods

Static functions are a natural fit for factory methods that create and return instances:

#include <memory>
#include <string>

class User {
    std::string name_;
    std::string email_;
    bool isAdmin_;

    // Private constructor
    User(std::string name, std::string email, bool isAdmin)
        : name_(std::move(name))
        , email_(std::move(email))
        , isAdmin_(isAdmin) {}

public:
    // Named factory methods — clearer than overloaded constructors
    static std::unique_ptr<User> createUser(std::string name, std::string email) {
        return std::unique_ptr<User>(new User(std::move(name), std::move(email), false));
    }

    static std::unique_ptr<User> createAdmin(std::string name, std::string email) {
        return std::unique_ptr<User>(new User(std::move(name), std::move(email), true));
    }

    const std::string& name() const { return name_; }
    bool isAdmin() const { return isAdmin_; }
};

int main() {
    auto user = User::createUser("Alice", "[email protected]");
    auto admin = User::createAdmin("Bob", "[email protected]");

    std::cout << user->name() << " admin=" << user->isAdmin() << '\n';   // Alice admin=0
    std::cout << admin->name() << " admin=" << admin->isAdmin() << '\n'; // Bob admin=1
}

Thread Safety for Static Members

Static data members shared across threads need synchronization: everything reachable through ClassName::member is exactly as shared as a global variable, and inherits every data race that comes with globals unless you actively protect it. The mutex_ in the example below is deliberately declared static alongside the data it protects — a common mistake is to protect a static member with a non-static (per-instance) mutex, which does nothing at all for the actual shared resource, since each instance would be locking its own private mutex while other threads freely race on the one piece of data that’s actually shared.

#include <atomic>
#include <mutex>
#include <thread>
#include <iostream>
#include <string>
#include <vector>

class EventBus {
    // Wrong: ++ is read-modify-write, not atomic
    // static int eventCount_;

    // Correct: atomic for simple counters
    static std::atomic<int> eventCount_;

    // For complex state: use mutex
    static std::mutex mutex_;
    static std::vector<std::string> log_;

public:
    static void emit(const std::string& event) {
        ++eventCount_;  // atomic — safe from multiple threads

        std::lock_guard<std::mutex> lock(mutex_);
        log_.push_back(event);
    }

    static int count() { return eventCount_.load(); }
};

std::atomic<int> EventBus::eventCount_{0};
std::mutex EventBus::mutex_;
std::vector<std::string> EventBus::log_;

int main() {
    std::thread t1([]{ for (int i = 0; i < 100; i++) EventBus::emit("click"); });
    std::thread t2([]{ for (int i = 0; i < 100; i++) EventBus::emit("hover"); });
    t1.join(); t2.join();

    std::cout << "Total events: " << EventBus::count() << '\n';  // 200
}

Initialization Order Problem

Static data members in different translation units have an unspecified initialization order. This can cause the “static initialization order fiasco”:

// a.cpp
int A::value = computeA();  // runs before or after B::value?

// b.cpp
int B::value = computeB();  // unspecified order

// If computeA() reads B::value — B::value might be zero!

This bug is unpleasant to track down because the order is not random at run time but fixed by the build: in practice it follows the order in which object files are passed to the linker. So the program works for months, and then an unrelated change (a new source file, a renamed file that sorts differently, a switch from Make to Ninja, or turning on LTO) reorders the link line and a config value starts reading as zero at startup. The symptom looks like a heisenbug, but it reproduces perfectly in a given build. No compiler warns about the ordering itself; Clang’s -Wglobal-constructors at least lists every global that needs a dynamic initializer, which is where to look.

Solution: use function-local statics (lazy initialization). They are initialized on first use, not at some unspecified point during program startup:

class Registry {
public:
    static std::map<std::string, int>& data() {
        static std::map<std::string, int> m;  // initialized on first call
        return m;
    }
};

// Safe even from another TU's static initializer — data() constructs m on first use
Registry::data()["key"] = 42;

If another translation unit’s static initializer calls data(), the map is constructed right then, before it is returned, so no caller can ever observe it unconstructed. What this does not solve is the destruction side described earlier: a global destructor that calls data() after the map has already been destroyed is still undefined behavior. When that matters, the usual workaround is to allocate the object with new inside the function and never delete it (static auto* m = new std::map<std::string, int>;), trading a deliberate “leak” at exit for an object that is valid until the process ends. C++20’s constinit is the other tool: it requires a static to be initialized at compile time, which removes it from dynamic initialization order entirely, and turns an accidental dynamic initializer into a compile error.

Static Members in Templates and Shared Libraries

“Exactly one copy” has two exceptions that surprise people.

Each template specialization has its own static members. In template <typename T> struct Counter { inline static int count = 0; };, Counter<int>::count and Counter<double>::count are different variables. That is often what you want (a per-type registry or ID generator), but a base class template that counts “all instances” counts per T, and a CRTP base gives every derived class its own copy. To share one value across all specializations, move it to a non-template base class.

Shared libraries may each get their own copy. On Windows, a static member defined in a header-only library (for example with inline static) and used from both an .exe and a DLL exists once in each module unless it is explicitly exported, so a singleton “instance” in the DLL is not the one the executable sees. On Linux, symbols from shared objects are usually merged by the dynamic linker, but -fvisibility=hidden, RTLD_LOCAL plugins or static linking of the same library into two shared objects bring the duplicate back. When a singleton appears to lose its state across a library boundary, check how many copies of it exist before debugging the logic.

Static member rules to remember

  • Static data members are shared by all instances — declared in the class, defined in exactly one .cpp
  • C++17 inline static allows in-class definitions — no separate .cpp entry needed
  • Static member functions have no this — called as Class::function(), cannot access instance members
  • Meyers singleton (static local) is thread-safe since C++11 — the standard guarantees once-only initialization
  • Static factory methods give descriptive names to different object creation paths (better than overloaded constructors)
  • Thread safety: ++counter is not atomic — use std::atomic<int> or std::mutex for shared mutable state
  • Static initialization order: cross-TU initialization order is unspecified — use function-local statics to avoid the fiasco