static Data Member and static Function

Programming Language & Its Applications — C++ Constructs with Objects and Classes, NEC licence examination syllabus (Nepal Engineering Council).

Static Data Members and Static Functions

One copy shared by every object of the class — class-level state, not object-level.

🌍 Where this lives: static members are how a class keeps track of itself. An object counter, a shared configuration, a connection pool, a cache — all of them need exactly one instance of some data no matter how many objects exist. Java's static is the same keyword doing the same job; Python uses class attributes. And the singleton pattern, which you will meet in the software-engineering paper, is built entirely from a private constructor plus a static instance. Search "singleton pattern is an anti-pattern" after this page — it is one of the most productive arguments in software design, and understanding both sides makes you better at judging any global state.

Static data members

class Counter { static int count; ← DECLARATION inside the class int id; public: Counter() { id = ++count; } }; int Counter::count = 0; ← DEFINITION outside, required Why two lines? The in-class line only declares that the member exists; it allocates no storage. Storage must be defined exactly once in one translation unit — otherwise every .cpp including the header would define its own copy and the linker would report a duplicate symbol. Forgetting the definition gives: undefined reference to `Counter::count' which is a LINKER error, not a compiler error — a useful clue when you see it. PROPERTIES: · ONE copy exists, shared by all objects · exists even if ZERO objects have been created · not part of any object → does not affect sizeof · lifetime is the whole program · zero-initialised by default · accessible as Counter::count (preferred) or obj.count C++17 shortcut — inline, so no separate definition needed: static inline int count = 0; const static integral members can be initialised in-class: static const int MAX = 100; ✔ (integral only) static constexpr double PI = 3.14159; ✔ (any literal type)

object_counter.cpp

#include <iostream>

class Widget {
    static int liveCount;      /* currently alive     */
    static int totalCreated;   /* ever created        */
    int id;
public:
    Widget() : id(++totalCreated) {
        ++liveCount;
        std::cout << "  create #" << id
                  << "  live=" << liveCount << "\n";
    }
    ~Widget() {
        --liveCount;
        std::cout << "  destroy #" << id
                  << "  live=" << liveCount << "\n";
    }
    /* static function: no object needed to call it */
    static int getLive()  { return liveCount; }
    static int getTotal() { return totalCreated; }
    int getId() const { return id; }
};

/* the mandatory definitions */
int Widget::liveCount    = 0;
int Widget::totalCreated = 0;

int main() {
    std::cout << "before any object: live="
              << Widget::getLive() << "\n";

    Widget a;
    {
        Widget b, c;
        std::cout << "inside block: live="
                  << Widget::getLive() << "\n";
    }                       /* c and b destroyed */
    Widget d;

    std::cout << "live=" << Widget::getLive()
              << "  total ever created=" << Widget::getTotal()
              << "\n";
    std::cout << "sizeof(Widget) = " << sizeof(Widget)
              << " (only the int id — statics are elsewhere)\n";
    return 0;
}
Output:
before any object: live=0
  create #1  live=1
  create #2  live=2
  create #3  live=3
inside block: live=3
  destroy #3  live=2
  destroy #2  live=1
  create #4  live=2
live=2  total ever created=4
sizeof(Widget) = 4 (only the int id — statics are elsewhere)

Two counters, two different questions answered: totalCreated only ever increments → 4 objects were made liveCount goes up and down → 2 are alive now The block created b(#2) and c(#3), then destroyed them in reverse order (#3 then #2 — the LIFO rule again), so live fell from 3 back to 1 before d(#4) pushed it to 2. And sizeof(Widget) = 4, not 12. The two statics live in static storage, outside every object, so adding more static members never makes objects bigger. This is a genuinely useful property: a class can carry a large shared lookup table at zero per-object cost.

Static member functions

static int getLive() { return liveCount; } A static member function: · has NO this pointer · therefore CANNOT access non-static members · CAN access static members · can be called WITHOUT an object: Widget::getLive() · cannot be const (nothing to be const about) · cannot be virtual (virtual dispatch needs an object) class C { int x; static int s; public: static void f() { s = 1; ✔ static member x = 1; ✗ error: invalid use of member 'x' in static member function } }; WHEN TO USE: · factory functions that create objects · utility functions logically grouped with the class but needing no object (Math::sqrt style) · accessors for static data · callbacks for C APIs that take a plain function pointer (a non-static member cannot be used — it needs this)

static_functions.cpp

#include <iostream>
#include <string>

class Temperature {
    double celsius;
    /* private ctor: objects only via the factories */
    explicit Temperature(double c) : celsius(c) {}
public:
    /* FACTORY functions — named constructors.
       Two "constructors from a double" are impossible as
       overloads, but as named statics they are clear. */
    static Temperature fromCelsius(double c) {
        return Temperature(c);
    }
    static Temperature fromFahrenheit(double f) {
        return Temperature((f - 32) * 5.0 / 9.0);
    }
    static Temperature fromKelvin(double k) {
        return Temperature(k - 273.15);
    }

    /* pure utility — needs no object at all */
    static double c2f(double c) { return c * 9.0/5.0 + 32; }

    double get() const { return celsius; }
};

class IdGenerator {
    static int next;
public:
    static int generate() { return next++; }
    static void reset()   { next = 1; }
};
int IdGenerator::next = 1;

int main() {
    auto a = Temperature::fromCelsius(100);
    auto b = Temperature::fromFahrenheit(98.6);
    auto c = Temperature::fromKelvin(300);
    std::cout << "100 C      = " << a.get() << " C\n";
    std::cout << "98.6 F     = " << b.get() << " C\n";
    std::cout << "300 K      = " << c.get() << " C\n";
    std::cout << "c2f(37)    = " << Temperature::c2f(37)
              << " F  (no object created)\n";

    std::cout << "ids: ";
    for (int i = 0; i < 5; i++)
        std::cout << IdGenerator::generate() << " ";
    IdGenerator::reset();
    std::cout << "| after reset: "
              << IdGenerator::generate() << "\n";
    return 0;
}
Output:
100 C      = 100 C
98.6 F     = 37 C
300 K      = 26.85 C
c2f(37)    = 98.6 F  (no object created)
ids: 1 2 3 4 5 | after reset: 1

Checking: (98.6 − 32) × 5/9 = 66.6 × 0.5556 = 37 ✔ 300 − 273.15 = 26.85 ✔ 37 × 9/5 + 32 = 66.6 + 32 = 98.6 ✔ The factory pattern solves a real problem here. As constructors these would be: Temperature(double c); /* celsius? */ Temperature(double f); /* fahrenheit? */ ✗ IMPOSSIBLE — same signature, cannot overload Named static factories give each meaning its own name, and the reader of `Temperature::fromFahrenheit(98.6)` cannot misunderstand it. That readability is why factories appear throughout real libraries.

Making the constructor private and exposing only static factories is a genuine design tool, not a trick. It guarantees every object goes through code you control, which means you can validate, cache, return a subclass, or return an existing instance instead of a new one — none of which a plain constructor can do, because a constructor must always produce a fresh object.

Worked example — a bank with shared state

bank_static.cpp

#include <iostream>
#include <string>

class Account {
    static double interestRate;    /* bank-wide */
    static int    accountCount;
    static double totalDeposits;

    std::string owner;
    double      balance;
    int         accNo;
public:
    Account(const std::string &o, double b)
        : owner(o), balance(b) {
        accNo = ++accountCount;
        totalDeposits += b;
    }

    void deposit(double amt) {
        if (amt <= 0) return;
        balance += amt;
        totalDeposits += amt;      /* shared total updates */
    }

    double yearEndBalance() const {
        return balance * (1 + interestRate / 100.0);
    }

    /* one call changes the rate for EVERY account */
    static void setRate(double r) { interestRate = r; }
    static double getRate()       { return interestRate; }
    static int    count()         { return accountCount; }
    static double bankTotal()     { return totalDeposits; }

    void show() const {
        std::cout << "  #" << accNo << " " << owner
                  << ": Rs " << balance
                  << " -> year end Rs " << yearEndBalance()
                  << "\n";
    }
};

double Account::interestRate  = 5.0;
int    Account::accountCount  = 0;
double Account::totalDeposits = 0.0;

int main() {
    Account a("Ram",  10000);
    Account b("Sita", 20000);
    Account c("Hari", 50000);
    b.deposit(5000);

    std::cout << "accounts=" << Account::count()
              << "  bank total=Rs " << Account::bankTotal()
              << "  rate=" << Account::getRate() << "%\n";
    a.show(); b.show(); c.show();

    std::cout << "\nRBI raises the rate to 8.5%:\n";
    Account::setRate(8.5);
    a.show(); b.show(); c.show();
    return 0;
}
Output:
accounts=3  bank total=Rs 85000  rate=5%
  #1 Ram: Rs 10000 -> year end Rs 10500
  #2 Sita: Rs 25000 -> year end Rs 26250
  #3 Hari: Rs 50000 -> year end Rs 52500

RBI raises the rate to 8.5%:
  #1 Ram: Rs 10000 -> year end Rs 10850
  #2 Sita: Rs 25000 -> year end Rs 27125
  #3 Hari: Rs 50000 -> year end Rs 54250

Verifying: bank total = 10000 + 20000 + 50000 + 5000 = 85000 ✔ at 5%: 10000 × 1.05 = 10500 ✔ 25000 × 1.05 = 26250 ✔ 50000 × 1.05 = 52500 ✔ at 8.5%: 10000 × 1.085 = 10850 ✔ 25000 × 1.085 = 27125 ✔ 50000 × 1.085 = 54250 ✔ The design point: ONE assignment — Account::setRate(8.5) — changed the calculation for all three accounts. Storing the rate per object would need a loop over every account, and would allow them to drift out of sync. Data that is logically a property of the CLASS belongs in a static member. The counterpoint worth knowing: static data is global state. It makes unit testing harder (tests share it and affect each other), and in multithreaded code every static member is a data race unless protected. That is the real cost.

🌍 Go further: static members have a subtle and famous problem called the static initialisation order fiasco: statics in different translation units are initialised in an unspecified order, so if one static's constructor uses another from a different .cpp file, it may read an uninitialised object. The standard fix is a function-local static, which C++11 guarantees is initialised exactly once and thread-safely on first use — the "construct on first use" idiom. Search "static initialization order fiasco"; it is the kind of bug that appears only in release builds on one machine, and knowing its name saves days.

💡 Exam angle: state that a static data member is shared by all objects, exists without any object, must be defined outside the class, and does not contribute to sizeof. The object counter program is the standard question — write it with both a live count and a total. For static member functions, the key facts are: no this, cannot access non-static members, callable as Class::func(), and cannot be const or virtual. Mention the forgotten-definition linker error as a practical detail.

Syllabus points

Static members & functions

Create a free account to tick topics off, take notes as you read, watch the video lessons and get a day-by-day study plan built around your exam date.