C++, End to End

More on Classes

Classes have more machinery than constructors and access specifiers. This page covers the rest of what you'll actually use: static members, const correctness on member functions, friends, delegating constructors, and the rule that decides whether you need to write your own copy/move/destructor logic at all.

Static members

A static data member belongs to the class itself, not to any one object. Every instance shares the same one. A static member function can be called without an object at all, and (because it isn't tied to an instance) has no this pointer, so it can only touch other static members.

c++ · live, editable, runnableOpen in Compiler Explorer ↗

#include <iostream> class Widget { static int count; // declaration only; needs a definition outside the class public: Widget() { ++count; } ~Widget() { --count; } static int activeCount() { return count; } }; int Widget::count = 0; // the one required definition, usually in a .cpp file int main() { { Widget a, b, c; std::cout << Widget::activeCount() << "\n"; // 3 } std::cout << Widget::activeCount() << "\n"; // 0, all three destructed }

A static data member needs exactly one definition somewhere (traditionally a .cpp file), separate from its declaration in the class. static inline int count = 0; inside the class (C++17 and later) lets you skip the separate definition entirely, and is the easier default now.

Const member functions

Marking a member function const promises it won't modify the object it's called on. This isn't just documentation. The compiler enforces it: a const member function can't assign to member variables, and it's the only kind of member function you can call on a const object or through a const reference.

c++ · live, editable, runnableOpen in Compiler Explorer ↗

#include <iostream> class Box { double volume; public: Box(double v) : volume(v) {} double getVolume() const { return volume; } // read-only, correctly const void scale(double factor) { volume *= factor; } // mutates, not const void describe(const Box& b) const { std::cout << b.getVolume() << "\n"; // fine: getVolume() is const // b.scale(2.0); would not compile: b is a const reference, // scale() isn't a const member function } }; int main() { Box b(10.0); b.describe(b); }

Get in the habit of marking every member function const unless it genuinely needs to mutate the object. It costs nothing, and it lets the rest of your code pass objects by const& freely, which is the default you want for anything you're not modifying.

Friend functions and classes

A friend declaration gives an outside function or class access to your private members, as if it were a member itself. It breaks encapsulation on purpose, for one specific relationship, and should be used sparingly: reach for it only when two things are so tightly coupled that a clean public interface between them would be more awkward than the access hole.

c++ · live, editable, runnableOpen in Compiler Explorer ↗

#include <iostream> class Matrix; // forward declaration class Vector3 { double data[3]; public: Vector3(double x, double y, double z) : data{x, y, z} {} friend class Matrix; // Matrix can reach into Vector3's private data void print() const { std::cout << data[0] << ", " << data[1] << ", " << data[2] << "\n"; } }; class Matrix { public: void zeroOut(Vector3& v) { v.data[0] = v.data[1] = v.data[2] = 0.0; // allowed only because of the friend declaration } }; int main() { Vector3 v(1, 2, 3); Matrix m; m.zeroOut(v); v.print(); // 0, 0, 0 }

The classic sign you're overusing friend: if you find yourself making half the codebase a friend of one class, that class's public interface is probably missing something it should expose properly instead.

Delegating constructors

A constructor can call another constructor of the same class in its initializer list, instead of duplicating setup logic. This is delegation, and it keeps constructors that differ only by defaults from repeating themselves.

c++ · live, editable, runnableOpen in Compiler Explorer ↗

#include <iostream> class Circle { double radius; std::string label; public: Circle(double r, std::string l) : radius(r), label(std::move(l)) {} Circle(double r) : Circle(r, "unnamed") {} // delegates to the constructor above Circle() : Circle(1.0) {} // delegates again void print() const { std::cout << label << ": r=" << radius << "\n"; } }; int main() { Circle a(5.0, "big"); Circle b(2.0); Circle c; a.print(); b.print(); c.print(); }

Default member initializers

You can give a member variable a default value right where it's declared. Any constructor that doesn't explicitly initialize that member in its own list picks up the default automatically. This removes a whole class of "forgot to initialize a field in one of three constructors" bugs.

c++ · live, editable, runnableOpen in Compiler Explorer ↗

#include <iostream> class Config { int timeoutSeconds = 30; // default member initializer bool verbose = false; public: Config() = default; // uses both defaults Config(int timeout) : timeoutSeconds(timeout) {} // overrides just one void print() const { std::cout << timeoutSeconds << ", " << verbose << "\n"; } }; int main() { Config a; Config b(60); a.print(); // 30, 0 b.print(); // 60, 0 }

The rule of zero, three, and five

If a class manages a resource directly (raw memory via new, a file handle, a socket), the compiler-generated copy constructor, copy assignment operator, and destructor will do the wrong thing: they copy the pointer, not what it points to. Two objects end up owning the same resource, and when both destructors run, you get a double free.

c++ · live, editable, runnableOpen in Compiler Explorer ↗

#include <iostream> #include <cstring> class BadBuffer { char* data; public: BadBuffer(const char* text) { data = new char[std::strlen(text) + 1]; std::strcpy(data, text); } ~BadBuffer() { delete[] data; } // No copy constructor or copy assignment written: the compiler generates ones // that just copy the "data" pointer, not the buffer it points to. }; int main() { BadBuffer a("hello"); BadBuffer b = a; // compiler-generated copy: b.data now points at the SAME memory as a.data // When main() ends, both a and b are destructed, and both destructors call // delete[] on the same pointer. That's a double free: undefined behavior. }

Don't run the example above for real, it's a genuine double free. The point is to see why the bug exists, not to trigger it.

The fix is either the rule of three (write a copy constructor, copy assignment operator, and destructor together, since needing one strongly implies needing the other two) or, better, the rule of zero: don't manage the raw resource yourself at all. Wrap it in a type that already does this correctly, like std::string, std::vector, or a smart pointer, and let your class's compiler-generated special members work by simply calling that member's own correct versions.

c++ · live, editable, runnableOpen in Compiler Explorer ↗

// godbolt-run #include <iostream> #include <string> class GoodBuffer { std::string data; // owns its own memory correctly; no manual new/delete anywhere public: GoodBuffer(const char* text) : data(text) {} void print() const { std::cout << data << "\n"; } // No copy constructor, copy assignment, or destructor written at all. // The compiler-generated ones just copy/destroy the std::string member, // which already does the right thing. }; int main() { GoodBuffer a("hello"); GoodBuffer b = a; // a real, independent copy of the string, no shared ownership b.print(); a.print(); }

Rule of five extends rule of three to also cover move constructor and move assignment, which matter once you care about avoiding unnecessary copies (the dedicated move semantics chapter elsewhere in this course covers that in depth). The practical takeaway is the same either way: reach for rule of zero by default, and only write the special members yourself when your class is the one place directly responsible for owning a raw resource.

Try it yourself: spot the missing rule-of-three piece›

This class manages a raw array itself, and writes a destructor and copy constructor, but is still broken. Find the missing piece, and explain what goes wrong without it.

c++

class IntArray {
    int* data;
    int size;
public:
    IntArray(int n) : size(n) { data = new int[n]{}; }
    ~IntArray() { delete[] data; }

    IntArray(const IntArray& other) : size(other.size) {
        data = new int[size];
        for (int i = 0; i < size; ++i) data[i] = other.data[i];
    }
    // No copy assignment operator (operator=) written.
};

Without a copy assignment operator, IntArray a(5); IntArray b(3); b = a; uses the compiler-generated one, which just copies the data pointer field, not the array. Now a and b share one buffer, and both destructors will eventually delete[] it. If you write the copy constructor, you almost always need the copy assignment operator too, that's the actual content of "rule of three": these three members come as a package, not a menu.