108. Access Specifier Enforcement

#include <iostream>
using namespace std;

// Base driver class
class BaseDriver {
private:
    int privateValue;

protected:
    int protectedValue;

public:
    int publicValue;

    BaseDriver(int val1, int val2, int val3)
        : privateValue(val1), protectedValue(val2), publicValue(val3) {
    }

    void function1(){
        cout << "function1 privateValue = " << privateValue << endl;
        cout << "function1 protectedValue = " << protectedValue << endl;
        cout << "function1 publicValue = " << publicValue << endl;
    }
};

// Derived driver class
class DerivedDriver : public BaseDriver {
public:
    DerivedDriver(int val1, int val2, int val3)
        : BaseDriver(val1, val2, val3) {
    }

    void function2(){
        // cout << "function2 privateValue = " << privateValue << endl;   // illegal
        cout << "function2 protectedValue = " << protectedValue << endl;
        cout << "function2 publicValue = " << publicValue << endl;
    }
};

int main() {
    int val1, val2, val3;
    cin >> val1 >> val2 >> val3;

    DerivedDriver driver(val1, val2, val3);
    driver.function1();
    driver.function2();

    // cout << "main() privateValue = " << driver.privateValue << endl;   // illegal
    // cout << "main() protectedValue = " << driver.protectedValue << endl; // illegal
    cout << "main() publicValue = " << driver.publicValue << endl;

    return 0;
}

Explanation & Logic Summary

• private members
  • Accessible only within the class where they are declared
  • Not accessible from derived classes or non-member code
• protected members
  • Accessible within the declaring class and its derived classes
  • Not accessible from non-member code such as main()
• public members
  • Accessible from anywhere the object is visible

C++ enforces these access rules at compile time, which is why illegal access attempts result in compilation errors. The correct resolution is to remove (comment out) only the invalid access statements.

Firmware Relevance & Real-World Context

In embedded firmware development:

• private protects low-level hardware details and internal driver state
• protected enables controlled extension of drivers without exposing internals
• public defines the safe interface exposed to application-level code

This compile-time enforcement prevents unsafe access patterns before firmware is even built, improving system reliability and maintainability.