Noesis
5.2.5 · D5C++ Programming

Question bank — Classes — member functions, access specifiers (public, private, protected)

1,418 words6 min read↑ Back to topic

This bank drills the boundaries of the parent topic and its neighbours: Encapsulation & Data Hiding, Inheritance in C++, struct vs class, this pointer, const correctness, and friend functions and classes.

True or false — justify

True or false: private means each object hides its data from other objects.
False. Access is per-class, not per-object — a member function can freely read another same-class object's private data (return balance > other.balance;). The wall stands between classes, not instances.
True or false: A struct cannot have member functions or private members.
False. A struct can have everything a class has (functions, private, constructors). The ONLY difference is the default access level: struct defaults to public, class to private.
True or false: protected members are accessible from main() if main() creates an object of the class.
False. protected behaves like private toward the outside world; only the class itself and its derived classes may touch it. main() is outside code, so c.name = "x"; is rejected.
True or false: Marking a member function const makes the whole object immutable.
False. It promises that one function won't modify the object's members. Other non-const functions on the same object can still change state; const is a per-function promise, tied to const correctness.
True or false: A public member function can still access private members of its own class.
True. The public/private wall is about who may call/reach a member from outside. Inside any member function (public or not) all of the class's own private data is fully visible.
True or false: If you write no access specifier at the top of a class, the members are public.
False. In a class the default is private. You'd get public by default only in a struct — that's the single real difference, per struct vs class.
True or false: A derived class can access the private members of its base class.
False. private base members are hidden even from children; that's precisely why protected exists — the "family-only" zone in Inheritance in C++.
True or false: Two objects of the same class share the same copy of each member variable.
False. Each object gets its own copy of the member variables. What they share is the member-function code — one blueprint, many independent cookies.

Spot the error

double area() { return width * height; } called as const Rectangle r; r.area(); — what's wrong?
area() is missing const, so the compiler can't prove it won't modify r. Calling a non-const function on a const object is rejected. Fix: double area() const {...}.
Inside main: acc.balance = 500; where balance is private — why does this fail?
balance is only reachable from inside BankAccount's own member functions (and friends). main is outside code, so the compiler blocks it — the whole point of the wall.
void deposit(double a) { balance += a; } written outside the class as just void deposit(...) — what's missing?
The scope-resolution qualifier. It must be void BankAccount::deposit(double a) so the compiler knows this function belongs to BankAccount and may touch its private balance.
A const function contains balance = 0; — why won't it compile?
The const after the signature promises no member is modified; assigning to balance breaks that promise, and the compiler enforces it by erroring.
class B : public A tries name = "x"; where name is private (not protected) in A — error?
Yes. private base members are invisible to children. Only if A declared name as protected would the derived class be allowed to use it.
struct Point { int x; int y; }; then p.x = 3; in main — error or fine?
Fine. struct members default to public, so x is reachable from outside. (Had this been a class, x would be private and the line would fail.)

Why questions

Why have protected at all when we already have public and private?
Inheritance creates a middle case: children are "family" who should inherit internal machinery, but the outside world still must not see it. protected is exactly that family-only visibility.
Why route all data changes through member functions instead of exposing the variables?
The single door can also be a guard — it validates input (reject a negative width) so invalid states become unrepresentable. This is Encapsulation & Data Hiding earning its keep.
Why does the compiler block illegal access at compile time rather than at runtime?
Because access rules are known from the source alone. Catching violations before the program runs means bugs never reach a user; the compiler is a bouncer, not a fire alarm.
Why does every member function carry a hidden this pointer?
A single copy of the function code serves all objects, so each call needs to know which object's data to operate on. `this` points at that specific object, making balance mean this->balance.
Why mark a read-only function const even though it "obviously" changes nothing?
"Obvious to you" isn't "proven to the compiler." Without const the compiler can't guarantee safety, so const objects can't call it — and future edits that sneak in a modification go undetected.
Why is class default-private but struct default-public if they're otherwise identical?
It's a convention baked into the language: class signals "encapsulated object, hide by default," struct signals "plain aggregate of data, open by default." The compiler just picks a sensible default per keyword.
Why can a friend function reach private members from outside the class?
The class explicitly grants that trust by naming the function a friend; it's a deliberate, controlled hole in the wall, not a loophole — see friend functions and classes.

Edge cases

If a class has only private members and no public functions, can any outside code use it?
Practically no — with no public gateway, outside code can neither read nor modify anything (only friends or the class's own code could). Such a class is a sealed box with no buttons.
Can a member function of BankAccount read the private balance of a different BankAccount object?
Yes. Access is per-class: any BankAccount method may reach the private members of any BankAccount instance passed to it, e.g. other.balance.
What happens if you list public: then later private: then public: again in one class?
Each specifier governs everything until the next one appears; you may repeat them freely. Members after the second public: are public again — order and repetition are legal.
Can a const member function call a non-const member function on the same object?
No. Doing so could indirectly modify the object, breaking the const promise, so the compiler forbids it. A const function may only call other const functions on this.
Is it possible for a derived class to loosen an inherited member to more visibility than the base gave?
Not by touching the member's own access — a private base member stays hidden. Visibility of inherited members is governed by the inheritance mode (public/protected/private), a topic of Inheritance in C++.
If two objects call the same const member function, do they interfere with each other?
No. Each call receives its own this pointing to its own object's data, and const guarantees neither is modified — the shared code operates on separate state.

Connections