Classes

What it is and why it exists

A C++ class is a user-defined type. Its definition lists data members, member functions, nested types, and access rules. An object is one runtime instance of that type. Each object has its own non-static data members and works through the interface supplied by the same set of member functions.

A class keeps a concept’s representation beside its valid operations. A thermostat object, for example, can store the current temperature while accepting only settings supported by the device. Callers do not have to remember to repeat validation before every write because the type maintains the rule.

A rule that must hold between an object’s observable operations is a class invariant . Constructors establish it, and public member functions preserve it after changing state. private does not prove that the code is correct, but it reduces the number of paths that can bypass those checks.

You meet classes in value objects, configuration, resource handles, containers, and service interfaces. A class does not imply an inheritance hierarchy or require virtual functions. Many useful C++ classes contain only a few value-type members and a small set of direct operations.

How it works

A class definition introduces a type name and declares members between braces. When you call a non-static member function on an object expression, the function operates on that object; inside the function, this points to the current object. Writing width_ normally means the same member access as this->width_.

An access specifier controls where a name can be used. public members form the caller-visible interface, private members are accessible only to members and friends of the class, and protected also admits derived classes. Access is checked at compile time; it does not decide whether an object owns a piece of memory.

Members without an explicit access specifier are private in a class. The same definition written as a struct defaults to public. Otherwise, both forms can have constructors, member functions, templates, base classes, and access specifiers.

A constructor creates a usable object. It has no return type, and its name is determined by the class type. When an object is created, the compiler selects a viable constructor from the arguments, initializes bases and members first, and only then enters the constructor body.

A member initializer list appears between a constructor’s parameter list and body. This is where members are initialized; it is not shorthand for assignment. Reference members, const members, and members without default constructors all need suitable initialization before the body begins.

Non-static data members are initialized in declaration order inside the class, not the order written in the initializer list. Keeping both orders the same makes dependencies visible and avoids reading a member that is not initialized yet. Those members are destroyed in reverse order.

A trailing const qualifies the current object in a member function. For example, double area() const can be called on a const Rectangle and cannot modify the object’s data through ordinary member access. Observer functions that only read state should usually carry this qualifier.

An ordinary object creation follows these steps:

1. The compiler selects a constructor from the object definition and its arguments.
2. Virtual and direct base classes are initialized in the order required by the language.
3. Non-static data members are initialized in declaration order.
4. The constructor body runs checks or work that needs several initialized members.
5. Code uses the object through its public interface while the object is in scope.
6. At the end of its lifetime, the destructor body runs before members and bases are destroyed in reverse construction order.

This order lets member objects manage their own lifetimes. An outer object whose members are std::string, std::vector, or smart pointers usually needs no hand-written cleanup. Compiler-generated operations compose the behavior those members already provide.

Examples

The next four programs add access control, validation, copying, and lifetime tracing in stages. Each was compiled locally in C++23 mode with g++ and run; the displayed output is the actual result.

A minimal value type

Rectangle keeps its representation private and exposes only area calculation and scaling. A caller can change the dimensions, but cannot bypass the interface and change just one member directly.

The braced values 4.0 and 2.5 select the two-parameter constructor. Its initializer list writes both members before the constructor body runs. area() is const because computing an area does not need to change the object.

This small example does not reject negative dimensions. If the domain requires positive sizes, both the constructor and scale() must validate their input. Making the data private does not create that rule by itself.

Establishing an invariant during construction

Thermostat accepts only 5 through 30 degrees Celsius. Its default constructor delegates to the constructor that takes a temperature, so both creation paths share one validation rule.

#include <iostream>
#include <stdexcept>

class Thermostat {
public:
    Thermostat() : Thermostat(20) {}

    explicit Thermostat(int celsius) : celsius_(celsius) {
        validate(celsius_);
    }

    void set_temperature(int celsius) {
        validate(celsius);
        celsius_ = celsius;
    }

    [[nodiscard]] int temperature() const { return celsius_; }

private:
    static void validate(int celsius) {
        if (celsius < 5 || celsius > 30) {
            throw std::out_of_range{"temperature must be 5..30"};
        }
    }

    int celsius_;
};

int main() {
    Thermostat office;
    Thermostat lab{18};
    office.set_temperature(22);
    std::cout << "office: " << office.temperature() << '\n';
    std::cout << "lab: " << lab.temperature() << '\n';

    try {
        lab.set_temperature(2);
    } catch (const std::out_of_range& error) {
        std::cout << "rejected: " << error.what() << '\n';
    }
}

office: 22
lab: 18
rejected: temperature must be 5..30

The one-argument constructor is explicit, so an integer cannot silently become a Thermostat in a function call. Direct initialization such as Thermostat lab{18} still works. explicit prevents implicit conversion, not ordinary explicit construction.

validate() does not depend on a particular object, so it is a private static member. Both creation and mutation use it to check the same range. An invalid mutation throws before assignment, leaving the old temperature unchanged.

Composing value semantics from members

ReadingLog stores all its state in std::string and std::vector. The class does not manage a raw resource directly, so it declares no destructor, copy operation, or move operation.

#include <iostream>
#include <string>
#include <utility>
#include <vector>

class ReadingLog {
public:
    explicit ReadingLog(std::string owner)
        : owner_(std::move(owner)) {}

    void add(std::string title) {
        titles_.push_back(std::move(title));
    }

    [[nodiscard]] const std::string& owner() const { return owner_; }
    [[nodiscard]] std::size_t size() const { return titles_.size(); }

private:
    std::string owner_;
    std::vector<std::string> titles_;
};

int main() {
    ReadingLog original{"Mina"};
    original.add("The Left Hand of Darkness");

    ReadingLog copy = original;
    copy.add("Kindred");

    std::cout << original.owner() << ": " << original.size() << '\n';
    std::cout << copy.owner() << ": " << copy.size() << '\n';
}

Mina: 1
Mina: 2

The compiler-generated copy constructor copies each member. A copied std::vector owns separate element storage, so adding a title to copy does not change original. This design, where members compose the right behavior, is commonly called the Rule of Zero.

owner() returns a const reference. That avoids copying the string on every observation and stops the caller from changing the name through this interface. The reference also has a lifetime constraint: it remains valid only while the corresponding ReadingLog object and its owner_ member are alive.

Observing member construction and destruction

Report is composed of two Trace members. The output directly shows how declaration order determines construction and how destruction reverses that order.

#include <iostream>
#include <string>
#include <utility>

class Trace {
public:
    explicit Trace(std::string name) : name_(std::move(name)) {
        std::cout << "construct " << name_ << '\n';
    }

    ~Trace() {
        std::cout << "destroy " << name_ << '\n';
    }

private:
    std::string name_;
};

class Report {
public:
    Report() : header_{"header"}, body_{"body"} {
        std::cout << "report ready\n";
    }

    ~Report() {
        std::cout << "report done\n";
    }

private:
    Trace header_;
    Trace body_;
};

int main() {
    Report report;
    std::cout << "using report\n";
}

construct header
construct body
report ready
using report
report done
destroy body
destroy header

header_ is declared before body_, so it is constructed first. When main() ends, the Report destructor body runs before body_ and then header_ are destroyed. Report does not need to call its member destructors itself.

This tracing type prints lifetime events for teaching. Production classes rarely log from destructors because output can fail, contend on locks, or happen after the logging system has shut down. The useful part here is the language-defined order.

Pitfalls

Public representation breaks invariants

Fix: design the interface around domain operations, such as replacing the complete range after validating both arguments. If there is no relationship to protect, a simple struct with public data can be more honest than a ring of getters and setters.

Initializer lists cannot reorder members

Fix: declare the dependency first and the dependent member second, then keep the initializer list in the same order. Enable compiler warnings; -Wall -Wextra usually reports when list order differs from declaration order.

Assignment inside a constructor body

Fix: establish initial member values in the member initializer list. Reserve the body for checks or side effects that need several initialized members, and perform checks that may fail before external side effects when practical.

Accidental implicit conversions

Fix: declare such constructors explicit unless conversion is an intentional part of the interface. Use braced direct initialization at the call site to state that a new object of the type is wanted.

Memberwise copying of a raw owning pointer

Fix: prefer std::vector, std::string, or a smart pointer to express ownership, and follow the Rule of Zero. When a custom resource owner is necessary, design copying, moving, and destruction as a set; see cpp/raii, cpp/smart-pointers, and cpp/move-semantics for those details.

Observer functions without const

Fix: add const to observers that do not modify logical state, then compile call tests through a const reference. If a cache or other implementation detail genuinely changes in an observer, use mutable sparingly and never as a way around a public invariant.

Further reading

• C++ working draft: classes
• C++ working draft: constructors
• C++ working draft: member access control
• cppreference: classes