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

Конструкторы и деструкторы

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

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

⏱ --:--

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

Вопрос 1 из 20

Зачем однопараметрический конструктор часто помечают explicit?

Чтобы разрешить копирование Чтобы скрыть конструктор от наследников Чтобы запретить неявное преобразование аргумента в объект Чтобы конструктор вызывался только один раз Чтобы объект размещался в куче

Вопрос 2 из 20

Что произойдёт с `Distance d = 5;`, если конструктор explicit?

struct Distance { explicit Distance(int meters); };
Distance d = 5;

Код не компилируется; нужна прямая инициализация вроде `Distance d{5}` Ключ explicit влияет лишь на явные приведения и не меняет такую инициализацию Код скомпилируется, но результат преобразования не определён Сработает конструктор копирования из временного Distance, созданного неявно Будет вызван конструктор по умолчанию, а значение 5 проигнорируется

Вопрос 3 из 20

Какое значение получит Box через делегирующий конструктор по умолчанию?

#include <iostream>
struct Box {
    int value;
    Box(int v) : value(v) {}
    Box() : Box(7) {}
};
int main() { Box b; std::cout << b.value; }

7 14 Поведение не определено 0 Код не компилируется

Вопрос 4 из 20

Почему поле-ссылку нужно инициализировать в списке инициализации?

Требование относится лишь к ссылке на const; неконстантную ссылку можно назначить позже Поле-ссылка допустимо только у класса со статическим временем хранения Ссылка должна быть привязана при создании подобъекта и не может быть переназначена присваиванием в теле Без списка инициализации ссылка сначала связывается с временным объектом, а затем автоматически перепривязывается Тело конструктора выполняется до инициализации полей и должно подготовить адрес для ссылки

Вопрос 5 из 20

Какое объявление просит компилятор сгенерировать конструктор по умолчанию, даже если есть другие конструкторы?

class Config {
public:
    Config() = default;
    explicit Config(std::string path) : path_(std::move(path)) {}
private:
    std::string path_ = "default.ini";
};

`Widget() = default;` `default Widget();` `Widget(auto = {});` `Widget() noexcept = 0;` `Widget() = delete;`

Вопрос 6 из 20

В каком порядке создаются части объекта производного класса?

Виртуальные базы, обычные базы, поля, тело конструктора Порядок не определён Поля создаются в порядке списка инициализации Сначала производный класс, затем базовые Сначала тело конструктора, затем поля и базы

Вопрос 7 из 20

В какой последовательности сработают конструкторы и деструкторы полей объекта X?

#include <iostream>
struct A { A(){std::cout<<"A";} ~A(){std::cout<<"a";} };
struct B { B(){std::cout<<"B";} ~B(){std::cout<<"b";} };
struct X { A a; B b; };
int main(){ X x; }

Порядок не определён ABba BAba ABab BAab

Вопрос 8 из 20

Если конструктор третьего элемента массива объектов выбросил исключение, что произойдёт?

Третий элемент считается созданным до входа в тело конструктора и тоже будет разрушен Деструкторы первых элементов не вызываются, потому что объект массива не был создан целиком Память массива освобождается, но деструкторы уже созданных элементов не вызываются Первые два полностью созданных элемента будут разрушены в обратном порядке Будет вызван деструктор для всех элементов массива, включая тот, чей конструктор не завершился

Вопрос 9 из 20

Кто задаёт порядок инициализации обычных базовых классов?

Порядок перечисления базовых классов в объявлении производного класса Порядок, выбранный оптимизатором для конкретной сборки Лексикографический порядок имён базовых классов Порядок элементов в списке инициализации выбранного конструктора Порядок, в котором объектные файлы обработал линковщик

Вопрос 10 из 20

Какой объект разрушится первым при выходе из блока?

{
    File a("a.txt");
    File b("b.txt");
}

a Порядок зависит от размера объектов b Ни один, локальные объекты не разрушаются Оба одновременно

Вопрос 11 из 20

Когда вызывается деструктор локального объекта автоматического хранения?

Сразу после последнего явного обращения к переменной, даже если её область видимости ещё не закончилась Сразу после последнего использования При выходе из области видимости Только при нормальном return Только после вызова delete

Вопрос 12 из 20

Почему базовому полиморфному классу обычно нужен виртуальный деструктор?

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

Вопрос 13 из 20

Что опасно в деструкторе, который может выбросить исключение?

Финальный класс защищён от этой проблемы, потому что его деструктор не участвует в полиморфизме Выбрасывающий деструктор допустим, если он не является шаблонным и помечен `noexcept(false)` Среда сохраняет второе исключение до конца раскрутки, после чего выбрасывает оба по очереди Если уже идёт раскрутка стека, второе вышедшее наружу исключение приводит к `std::terminate` После throw деструктор автоматически запускается повторно для завершения очистки

Вопрос 14 из 20

Какой символ появится при удалении производного объекта через указатель B*?

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

Поведение не определено BD D B DB

Вопрос 15 из 20

Какой подход лучше для закрытия файлового дескриптора?

Хранить дескриптор во владеющей RAII-обёртке и закрывать его в деструкторе Освобождать числовой дескриптор через delete после последней операции ввода-вывода Возложить на каждый путь выхода обязанность вручную вызвать close и документировать порядок Закрывать дескриптор лишь при успешном завершении функции, а ошибки обрабатывать отдельно Оставлять дескриптор открытым до завершения процесса, полагаясь на системную очистку

Вопрос 16 из 20

Вызывается ли деструктор класса, если его конструктор не завершился из-за исключения?

Полный деструктор вызывается, если он виртуальный, иначе очистка зависит от типа исключения Полный деструктор класса не вызывается, но уже построенные базы и поля разрушаются Правило действует только для исключений, производных от `std::exception` Да: полный деструктор запускается после исключения и сам определяет, какие поля уже построены Нет; поскольку объект не создан, деструкторы уже построенных баз и полей также не вызываются

Вопрос 17 из 20

Где возможна утечка?

Owner::Owner() {
    a = new ResourceA;
    b = new ResourceB;
}

Утечка возможна только при return Если второй new бросит после успешного первого Оба new выполняются атомарно delete вызывается компилятором для всех сырых указателей Исключения не могут возникнуть в new

Вопрос 18 из 20

Как лучше переписать два владеющих поля, чтобы конструктор был безопасен при исключении?

class Service {
public:
    Service()
        : database_(std::make_unique<Database>()),
          cache_(std::make_unique<Cache>()) {}
private:
    std::unique_ptr<Database> database_;
    std::unique_ptr<Cache> cache_;
};

Инициализировать сырые указатели значением nullptr и освобождать их только в деструкторе Service Заменить владение ссылочными полями, привязанными к объектам, созданным через `new` Выделять оба объекта в теле конструктора и записывать адреса в поля сразу после каждого `new`, не вводя локальных владельцев Оставить сырые указатели и рассчитывать на деструктор Service, хотя объект Service ещё не построен полностью Хранить `std::unique_ptr<Database>` и `std::unique_ptr<Cache>` либо другие подходящие RAII-поля, как в примере

Вопрос 19 из 20

Что происходит с памятью, выделенной выражением `new T(args...)`, если конструктор T выбрасывает?

Widget* p = new Widget(config);
// если Widget(config) бросает, выделенный блок освобождается
// подходящей operator delete автоматически

Выделенный блок остаётся утерянным, потому что деструктор T не вызывался Среда обязана завершить программу до освобождения выделенной памяти Вызывается деструктор T, как если бы объект успел полностью сконструироваться После исключения вызывается подходящий `operator delete` для освобождения сырого блока Блок освобождается только тогда, когда конструктор выбрасывает `std::bad_alloc`

Вопрос 20 из 20

Какую гарантию должен давать фабричный метод `Connection::open()` при ошибке подключения?

class Connection {
public:
    static std::expected<Connection, Error> open(Address address);
    ~Connection();
private:
    explicit Connection(Socket socket);
    Socket socket_;
};

Оставлять частично заполненный Connection и требовать от клиента проверить каждое поле Возвращать объект с особым fd = -1, не включая это состояние в контракт типа Сохранять открытые до ошибки ресурсы внутри неуспешного результата, чтобы клиент закрыл их вручную Всегда создавать объект, а подробности сбоя записывать в общую глобальную переменную Возвращать полностью готовый Connection либо явный результат ошибки без утечки промежуточных ресурсов

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

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

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

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