В производном классе вызов read Base& не компилируется, хотя Base::value унаследован. Укажите причину, опир...

struct Base {
protected:
    int value = 42;
};

struct Derived : Base {
    int read(Derived& object) {
        return object.value;
    }

    int read(Base& object) {
        return object.value;
    }
};

Краткий ответ

Ошибка возникает во второй функции: внутри Derived защищённый член Base::value можно использовать через объект, статический тип которого является Derived или его производным классом. Статический тип параметра object — Base&, поэтому выражение object.value запрещено, даже если во время выполнения там фактически может находиться объект Derived.

Исторический контекст

Модификатор protected предназначен для расширения базового класса наследниками без предоставления доступа всем клиентам класса. При этом C++ ограничивает не только место обращения, но и тип объекта, через который наследник обращается к защищённому члену.

Это ограничение сохраняет инкапсуляцию между разными ветвями иерархии. Иначе один производный класс мог бы напрямую изменять защищённое состояние произвольного объекта базового класса, потенциально нарушая инварианты другого производного класса.

Постановка проблемы

Член функции Derived действительно имеет право обращаться к защищённым членам Base. Однако это право не означает, что ему разрешено обращаться к value через любой объект типа Base.

Здесь важно различать динамический тип объекта и статический тип выражения. Компилятор проверяет доступ на этапе компиляции и видит в read(Base&) только Base&; возможный динамический тип объекта не расширяет права доступа.

Подробное решение

В read(Derived&) выражение object.value корректно: параметр имеет тип Derived&, а Derived является классом, наследующим Base. В read(Base&) тот же доступ некорректен, потому что выражение имеет статический тип Base&.

Минимальный вариант с исправлением через защищённый метод базового класса выглядит так:

struct Base {
protected:
    int value = 42;

    int get_value() const { return value; }
};

struct Derived : Base {
    int read(Base& object) {
        return object.get_value();
    }
};

Вызов get_value() всё ещё подчиняется правилам доступа. Он разрешён, если сам метод доступен из Derived; его реализация обращается к value внутри Base, где доступ к собственному члену гарантирован.

Нельзя считать достаточным условие «объект фактически является Derived». Например, передача Derived через Base& стирает эту информацию на уровне статического типа. Безопасное приведение к Derived& возможно только при доказанном типе объекта, обычно через dynamic_cast, но это уже другой дизайн и потенциальная ошибка времени выполнения.

Правило защищает также от доступа к состоянию объекта, принадлежащего другой ветви наследования. Производный класс получает контролируемый доступ к защищённой части собственных объектов и объектов совместимых с ним производных классов, но не универсальный доступ к внутренностям любого Base.

Ситуация из практики

Предположим, базовый класс представляет узел AST, а производный класс BinaryNode хочет прочитать внутреннее поле узла, полученного как BaseNode&. Прямой доступ к защищённому полю не скомпилируется, поскольку тип параметра — BaseNode&.

Можно сделать поле публичным, но это разрушает инкапсуляцию. Можно использовать friend, однако это создаёт тесную связь между классами и расширяет права конкретного компонента.

Обычно выбирают защищённый метод базового класса, возвращающий нужное значение или выполняющий операцию. Такой вариант сохраняет контроль над представлением объекта и позволяет позднее изменить хранение поля без исправления всех производных классов.

Если операция действительно полиморфна, лучше объявить виртуальный публичный или защищённый интерфейс в базовом классе. Тогда код работает с BaseNode& через контракт базового класса, а не пытается получить доступ к деталям конкретного наследника.

Что кандидаты часто упускают

1. Меняется ли результат, если объект передан как Base&, но фактически создан как Derived?

Нет. Для проверки защищённого доступа важен статический тип выражения object, то есть Base&. Динамический тип влияет на виртуальный вызов и проверяется механизмами RTTI, но не отменяет правила доступа, установленного компилятором.

2. Разрешён ли такой доступ к объекту другого производного класса?

Нет, если обращение выполняется из Derived через объект статического типа OtherDerived&, где оба класса непосредственно наследуют Base. OtherDerived не является Derived или классом, производным от Derived, поэтому обращение к унаследованному защищённому члену через такой объект запрещено.

3. Что изменится, если value объявить как public?

Тогда обе функции скомпилируются, потому что публичный член доступен независимо от статического типа объекта, при условии что этот член существует в интерфейсе Base. Однако это предоставляет доступ всем клиентам и лишает класс возможности контролировать изменение состояния; для сохранения инвариантов предпочтительнее публичный или защищённый метод.