C++ C++ · 20 вопросов · ~55 мин · ⏱ Таймер 55:00 · Лёгкий ·

Наследование и виртуальные функции

Тест проверяет границу между “является” и “использует”, статический и динамический тип, скрытие перегрузок и безопасное разрушение полиморфных объектов. Вопросы построены так, чтобы привычная фраза про virtual не заменяла точный разбор вызова.

Отвечено: 0 из 20

⏱ --:--

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

Вопрос 1 из 20

Какой смысл обычно имеет public-наследование?

struct Shape {
    virtual double area() const = 0;
    virtual ~Shape() = default;
};
struct Circle final : Shape {
    double area() const override;
};
void print_area(const Shape& shape);

Наследование используется только ради экономии памяти Производный класс просто получает доступ ко всем private-полям Производный тип соблюдает публичный контракт базового Публичное наследование превращает все доступные методы Base в виртуальные Базовый объект хранится отдельно в куче

Вопрос 2 из 20

Может ли метод производного класса напрямую читать private-поле базового?

Да, если обращаться к полю через `this`, а не через имя объекта базы Да: public-наследование автоматически делает private-члены protected для производного класса Доступ зависит от const-квалификатора поля, а не от его спецификатора доступа Доступ разрешён, когда метод производного класса переопределяет виртуальную функцию базы Нет: нужен открытый или защищённый интерфейс базы либо явно предоставленная дружба

Вопрос 3 из 20

Что произойдёт при `Base b = Derived{};`?

struct Base { virtual ~Base() = default; };
struct Derived : Base { int extra = 42; };
Base b = Derived{};

b станет ссылкой на временный Derived Такое копирование запрещено, если Derived содержит дополнительные поля b сохранит полный динамический тип Derived Производная часть будет срезана, останется самостоятельный Base Производная часть будет доступна через dynamic_cast

Вопрос 4 из 20

Почему наследовать `Square` от изменяемого `Rectangle` с независимыми set_width/set_height часто проблематично?

class Rectangle {
public:
    virtual void set_width(int w) { width_ = w; }
    virtual void set_height(int h) { height_ = h; }
    int area() const { return width_ * height_; }
protected:
    int width_ = 1, height_ = 1;
};

class Square : public Rectangle {
public:
    void set_width(int w) override { width_ = height_ = w; }
    void set_height(int h) override { width_ = height_ = h; }
};

Проблема только в названии классов Square нарушает контракт независимых сторон Rectangle Квадрат математически не является прямоугольником Наследование запрещает поля double Виртуальные методы всегда медленные

Вопрос 5 из 20

Когда композиция обычно лучше наследования?

Когда нужен доступ к private-полям другого класса без изменения его публичного интерфейса Когда требуется заменяемое поведение через стабильный полиморфный интерфейс и действительно есть отношение подтипа Когда класс не должен содержать собственных полей и хранит только функции Когда составной объект обязан размещаться на стеке, а базовый — в динамической памяти Когда нужно использовать другой объект как часть реализации, но отношение «является» неверно

Вопрос 6 из 20

Какое имя выведет виртуальный вызов через ссылку Base&?

#include <iostream>
struct Base { virtual void name(){ std::cout << "base"; } };
struct Derived : Base { void name() override { std::cout << "derived"; } };
void show(Base& x){ x.name(); }
int main(){ Derived d; show(d); }

Код не компилируется derived Поведение не определено base basederived

Вопрос 7 из 20

Что происходит с виртуальным вызовом из конструктора Base?

Цель вызова не определена и может меняться между запусками одной сборки Вызывается реализация Base, потому что производная часть объекта ещё не начала своё время жизни как Derived Выбирается самая производная реализация: виртуальная диспетчеризация не зависит от фазы конструирования Любой виртуальный вызов в конструкторе является синтаксической ошибкой Сначала выполняется конструктор Derived, поэтому его override уже доступен Base

Вопрос 8 из 20

Что означает `virtual void draw() = 0;`?

struct Shape {
    virtual ~Shape() = default;
    virtual void draw(Canvas&) const = 0;
};

struct Circle final : Shape {
    void draw(Canvas&) const override;
};

Функция возвращает нулевое значение, если производный класс не предоставляет реализацию Метод становится статическим требованием интерфейса и вызывается без объекта Наличие pure virtual запрещает создавать новые производные классы без собственного определения draw Объявление полностью удаляет функцию и запрещает определение даже вне класса Функция является чисто виртуальной, а класс с такой функцией нельзя создавать напрямую

Вопрос 9 из 20

Можно ли вызвать static-метод виртуально?

Да, если возвращает указатель Да, если он public Только в C++23 Только через Base* Нет: static не бывает virtual

Вопрос 10 из 20

Почему вызов виртуальной функции из деструктора Base не попадёт в Derived?

Производная часть ещё не создана для текущего вызова, как во время конструктора Base Деструктор может вызывать только final-методы, поэтому виртуальный вызов заменяется невиртуальным Выбор Base — необязательная оптимизация; в отладочной сборке допустим вызов Derived В деструкторе виртуальные вызовы разрешены, но всегда выбирается последняя перегрузка, объявленная текстуально К моменту выполнения `~Base` производная часть уже разрушена, и диспетчеризация ограничена базовым подобъектом

Вопрос 11 из 20

Зачем писать override?

Чтобы запретить дальнейшее наследование класса Чтобы компилятор вставил вызов базовой реализации перед телом переопределения Чтобы сделать метод public Чтобы метод работал быстрее Проверку реального переопределения компилятором

Вопрос 12 из 20

Почему код не компилируется?

struct Base { virtual int value() const; };
struct Derived : Base { int value() override; };

Виртуальную функцию нельзя объявлять константной В Base метод имеет квалификатор `const`, а в Derived — нет: сигнатуры различаются Спецификатор `override` разрешён только у статических методов Переопределяемый метод базового класса обязан быть закрытым Виртуальная функция с возвращаемым типом `int` недопустима

Вопрос 13 из 20

Что делает final у виртуального метода?

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

Вопрос 14 из 20

Какой возвращаемый тип может быть ковариантным при переопределении?

Любой тип того же размера и выравнивания, совместимый на уровне ABI Указатель или ссылка на класс, более производный относительно результата базовой функции Контейнер производных значений вместо контейнера базовых значений Любой арифметический тип, неявно приводимый к типу результата базового метода Void вместо любого конкретного результата, поскольку отсутствие значения ковариантно

Вопрос 15 из 20

Что случилось в этом коде?

struct Base { virtual void f(int); };
struct Derived : Base { void f(double); };

Одинаковое имя заставляет Derived::f(double) переопределить все перегрузки f из Base Вызов любой из функций имеет неопределённое поведение из-за разных типов параметров Derived::f(double) скрывает имя f из Base, но не переопределяет Base::f(int) Объявление f в Derived превращает обе функции в чисто виртуальные до явного `using` После объявления производной перегрузки Base::f(int) становится статической функцией

Вопрос 16 из 20

Каково поведение `delete p`, если Base не имеет виртуального деструктора, а p указывает на Derived?

struct Base {
    ~Base() { std::cout << "Base"; }
};
struct Derived : Base {
    ~Derived() { std::cout << "Derived"; }
};

Base* p = new Derived;
delete p;

Код не компилируется Гарантированно вызываются оба деструктора При удалении через Base* объект Derived считается тривиально разрушаемым Неопределённое поведение Будет вызван только Base::~Base; это определённый и безопасный способ удалить Derived

Вопрос 17 из 20

Какой дизайн уместен для базового интерфейса, объекты которого удаляются через `std::unique_ptr<Base>`?

struct Device {
    virtual ~Device() = default;
    virtual void start() = 0;
};

std::unique_ptr<Device> make_device() {
    return std::make_unique<UsbDevice>();
}

Публичный виртуальный деструктор Только static-функция destroy без контракта Приватный невиртуальный деструктор без deleter protected поле delete Отсутствие деструктора

Вопрос 18 из 20

Зачем иногда делают невиртуальный деструктор Base protected?

Чтобы производные классы не могли вызывать деструктор Base при собственном разрушении Чтобы разрешить множественное наследование Чтобы ускорить создание Base на стеке Чтобы запретить delete через Base* Чтобы сделать все методы protected

Вопрос 19 из 20

Должен ли pure virtual-деструктор иметь определение?

Нет: запись `= 0` удаляет тело деструктора и базовая часть не разрушается Тело требуется лишь тогда, когда в базовом классе есть нетривиальные поля, нуждающиеся в ручной очистке Определение требуется, только если последний производный класс объявлен final Да: при разрушении производного объекта всё равно вызывается деструктор базового подобъекта Определение нужно лишь в сборке с отладочной информацией для формирования vtable

Вопрос 20 из 20

Какая строка вывода ожидается?

#include <iostream>
struct B { virtual ~B(){ std::cout << "B"; } };
struct D : B { ~D(){ std::cout << "D"; } };
int main(){ B* p = new D; delete p; }

D BD DB B Порядок не определён

Ответьте на все 20 вопросов, чтобы получить результат

🔗 Встроить тест на свой сайт (iframe) ▼

Скопируйте код и вставьте в любое место на вашем сайте:

Также доступна прямая ссылка на embed-страницу