C++ Access Specifiers: public, private, protected

Who Gets to Touch Your Data

When you wrote your first class you probably exposed every member to the outside world. That works, but it throws away one of the main reasons classes exist: encapsulation - hiding a class's internal state so the rest of the program can only interact with it through a controlled surface. Access specifiers are how you draw that boundary.

There are exactly three: public, private, and protected. Each one labels the members that follow it, and the label decides which code is allowed to read or write them. Get this right and your class enforces its own rules; get it wrong and any bug anywhere can corrupt your object's state.

The Three Specifiers

A specifier is a keyword followed by a colon. Every member declared after it - up to the next specifier - falls under that access level.

#include <iostream>
using namespace std;

class Account {
public:
    void deposit(double amount) { balance += amount; }  // anyone can call
    double getBalance() const { return balance; }       // anyone can read

private:
    double balance = 0.0;   // only Account's own code can touch this
};

int main() {
    Account a;
    a.deposit(100.0);
    cout << a.getBalance() << endl; // 100
    // a.balance = 999999;          // ERROR: balance is private
    return 0;
}

Uncomment the last line and the compiler refuses to build: balance is private, so main cannot poke at it directly. That's the point - the only way to change the balance is through deposit, which means you can later add validation (no negative deposits, logging, limits) in one place and trust it's always applied.

Here's the full breakdown:

//             reachable from...
// public      anywhere (any code that has the object)
// private     only the same class's own members (+ friends)
// protected   the same class's members AND derived classes (+ friends)

class vs struct: the Default

You can write as many specifier blocks as you like, in any order. What members get before you write the first one depends on whether you used class or struct:

• In a class, members are private by default.
• In a struct, members are public by default.

That default is the only language-level difference between the two keywords. A struct can have methods, constructors, and private sections just like a class.

#include <iostream>
using namespace std;

class Locked {
    int secret = 42;   // private by default - no specifier needed
};

struct Open {
    int value = 7;     // public by default
};

int main() {
    Open o;
    o.value = 99;           // fine: public
    cout << o.value << endl; // 99

    // Locked l;
    // l.secret = 1;         // ERROR: secret is private
    return 0;
}

Convention is to use struct for plain bundles of public data and class when you want behavior and hidden state - but the compiler doesn't enforce that, only the default differs.

Encapsulation with Getters and Setters

The everyday pattern is: data goes in a private section, and a public method gives controlled access. A read-only getter returns the value; a setter validates before assigning. This is where private pays off.

#include <iostream>
using namespace std;

class Temperature {
public:
    void setCelsius(double c) {
        if (c < -273.15) {          // physics says you can't go lower
            cout << "Ignoring impossible temperature\n";
            return;
        }
        celsius = c;
    }
    double getCelsius() const { return celsius; }
    double getFahrenheit() const { return celsius * 9.0 / 5.0 + 32.0; }

private:
    double celsius = 0.0;
};

int main() {
    Temperature t;
    t.setCelsius(25);
    cout << t.getCelsius() << " C = " << t.getFahrenheit() << " F\n";

    t.setCelsius(-500);             // rejected, state stays valid
    cout << t.getCelsius() << " C\n"; // still 25
    return 0;
}

Because celsius is private, there's no way to sneak an invalid value in - every write must go through setCelsius, which guards the invariant. Notice the getters are marked const: they promise not to modify the object, so you can call them on const Temperature objects too.

protected and Inheritance

protected only matters once inheritance enters the picture. It behaves like private for outside code, but a derived class can reach it. Use it for members a subclass legitimately needs but the public still shouldn't.

#include <iostream>
#include <string>
using namespace std;

class Animal {
protected:
    string name = "unknown";   // subclasses may use this...

public:
    void setName(const string& n) { name = n; }
};

class Dog : public Animal {
public:
    void speak() const {
        // 'name' is protected, so Dog can read it directly
        cout << name << " says Woof!\n";
    }
};

int main() {
    Dog d;
    d.setName("Rex");
    d.speak();            // Rex says Woof!
    // cout << d.name;    // ERROR: protected is off-limits to outside code
    return 0;
}

A common beginner mistake is reaching for protected on every data member "just in case a subclass needs it." That quietly widens your class's contract - now every subclass can depend on that field, and you can't change it freely. Prefer private and only promote to protected when a derived class genuinely needs the access.

The friend Escape Hatch

Sometimes a single outside function or class legitimately needs to see your internals - a classic case is operator overloading for <<, which you can't make a member. The friend keyword grants that one named entity access to your private and protected members, and nothing else.

#include <iostream>
using namespace std;

class Point {
public:
    Point(int x, int y) : x(x), y(y) {}

    // grant this specific function access to private members
    friend ostream& operator<<(ostream& os, const Point& p);

private:
    int x, y;
};

ostream& operator<<(ostream& os, const Point& p) {
    return os << "(" << p.x << ", " << p.y << ")"; // can read private x, y
}

int main() {
    Point p(3, 4);
    cout << p << endl; // (3, 4)
    return 0;
}

friend is a deliberate, surgical exception - the class itself names exactly who it trusts, so nobody can grant themselves access from the outside. Use it sparingly; if you find yourself adding lots of friends, your members probably shouldn't have been private in the first place, or your design needs rethinking.

Common Mistakes to Avoid

• Making every member public. It feels easy, but you lose all the validation and invariants encapsulation buys you. Default to private data with public methods.
• Forgetting the class default. class Foo { int x; }; makes x private, so foo.x = 5 won't compile. If you meant a plain data bundle, use struct or add a public: label.
• Overusing protected. It's a weaker boundary than private and only relevant with inheritance. Reaching for it everywhere couples subclasses to fields you may want to change.
• Expecting private to be a security feature. It's a compile-time rule that prevents accidental access, not encryption. The bytes are still in memory; private is about clean design, not secrecy.

Next: Structs

You've now seen that struct is really just a class whose members are public by default. The next page, structs, digs into when that public-by-default default is exactly what you want - lightweight aggregates for grouping related values - and how struct is used in idiomatic C++ alongside full-featured classes.