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

RAII и управление ресурсами

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

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

⏱ --:--

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

Вопрос 1 из 20

Какой тип лучше всего выражает единственное владение динамическим объектом?

std::unique_ptr<Widget> make_widget() {
    return std::make_unique<Widget>();
}

auto widget = make_widget();
widget->run();

`T*` без дополнительных соглашений `std::weak_ptr<T>` `std::shared_ptr<T>` всегда `std::unique_ptr<T>` `const T*`

Вопрос 2 из 20

Что произойдёт при передаче p в consume?

#include <memory>

void consume(std::unique_ptr<int> value) {
    (void)value;
}

int main() {
    auto p = std::make_unique<int>(7);
    consume(std::move(p));
}

Управляемый int уничтожится до входа в тело consume Значение будет скопировано, а p сохранит единственное владение Владение перейдёт параметру consume, а p после вызова станет пустым p и параметр consume станут двумя независимыми владельцами одного int Вызов потребует `p.release()`, потому что std::move недостаточно

Вопрос 3 из 20

Какая сигнатура яснее всего говорит “функция лишь наблюдает объект и допускает его отсутствие”?

void inspect(const Widget* widget) {
    if (!widget) return;
    std::cout << widget->name();
}

inspect(nullptr);
inspect(&existing);

`void inspect(Widget&& widget)` `void inspect(std::shared_ptr<Widget> widget)` `void inspect(Widget widget)` `void inspect(std::unique_ptr<Widget> widget)` `void inspect(const Widget* widget)`

Вопрос 4 из 20

Почему возвращать сырой указатель из фабрики `create()` опасно без строгого соглашения?

Widget* create_widget();

void run() {
    Widget* widget = create_widget();
    process(*widget);
    // Кто и каким способом должен освободить widget?
}

Проблема только в длине имени функции Объект всегда будет размещён в стеке Возвращаемый сырой указатель становится указателем на const и поэтому не требует освобождения Непонятно, обязан ли вызывающий код вызвать delete и какой именно Сырые указатели нельзя возвращать из функций

Вопрос 5 из 20

Какой контракт наиболее разумен для метода `Widget* parent() const`?

class Widget {
public:
    Widget* parent() const noexcept { return parent_; }
private:
    Widget* parent_ = nullptr; // невладеющая, допускающая отсутствие связь
};

Метод каждый раз выделяет нового родителя Вызывающий обязан удалить parent Невладеющий указатель; parent жив снаружи, nullptr допустим Указатель гарантированно действителен после уничтожения текущего объекта const запрещает возвращать указатель

Вопрос 6 из 20

Закроется ли файл при раннем return?

#include <fstream>
bool save(bool skip) {
    std::ofstream file("out.txt");
    if (skip) return false;
    file << "data";
    return true;
}

Да: автоматический объект file будет разрушен при выходе из функции через return Файл останется открыт до завершения процесса, если функция не дошла до последней строки Нет: деструкторы не вызываются при раннем return, поэтому close нужен перед каждой точкой выхода Закрытие зависит от типа возвращаемого значения функции Деструктор локального объекта вызывается только в оптимизированной сборке

Вопрос 7 из 20

Почему явный `delete p` рядом с unique_ptr опасен?

auto owner = std::make_unique<int>(5);
int* p = owner.get();
delete p;

unique_ptr позже попытается удалить тот же объект ещё раз После явного delete unique_ptr распознает освобождённый адрес и сбросит его перед деструктором Ошибка только в том, что p не const Код не компилируется, потому что p не указатель delete ничего не делает для int

Вопрос 8 из 20

В каком порядке освободятся guard и file при выходе из блока?

File file("log.txt");
LockGuard guard(mutex);

Оба объекта живут до завершения программы, поскольку управляют внешними ресурсами Сначала file, затем guard, потому что файл был создан раньше Сначала guard, затем file — в порядке, обратном завершённому конструированию Оптимизатор может менять наблюдаемый порядок деструкторов для ускорения выхода Порядок разрушения локальных объектов одной области не определён

Вопрос 9 из 20

Какой эффект даёт `std::lock_guard<std::mutex> lock(m);`?

std::mutex mutex;
std::vector<Event> events;

void append(Event event) {
    std::lock_guard<std::mutex> lock(mutex);
    events.push_back(std::move(event));
}

Блокировка происходит только при исключении Мьютекс остаётся заблокированным навсегда Устанавливает приоритет мьютекса выше, чем у вызывающего потока Создаётся копия мьютекса Блокирует в конструкторе, разблокирует в деструкторе

Вопрос 10 из 20

Почему RAII упрощает обработку исключений?

Очистка уже созданных объектов выполняется раскруткой стека Компилятор заменяет исключения кодами возврата Все ресурсы становятся глобальными RAII действует только без исключений Исключения перестают возникать

Вопрос 11 из 20

Как завернуть FILE* так, чтобы fclose вызывался автоматически?

using File = std::unique_ptr<FILE, decltype(&std::fclose)>;

File file(std::fopen("data.bin", "rb"), &std::fclose);
if (!file)
    throw std::system_error(errno, std::generic_category());

`std::shared_ptr<FILE>` со стандартным deleter, вызывающим `delete` вместо `fclose` `std::unique_ptr<FILE>` со стандартным delete для объекта, созданного fopen `std::vector<FILE>`, где закрытие происходит при удалении элемента `const FILE*`, поскольку const заставляет runtime закрыть поток `std::unique_ptr<FILE, decltype(&std::fclose)>` с корректно переданным deleter

Вопрос 12 из 20

Что должен делать перемещающий конструктор обёртки сокета?

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

Вопрос 13 из 20

Какой deleter нужен для памяти от `malloc`?

using Buffer = std::unique_ptr<std::byte, decltype(&std::free)>;

void* raw = std::malloc(4096);
if (!raw) throw std::bad_alloc{};
Buffer buffer(static_cast<std::byte*>(raw), &std::free);

`std::free` `std::fclose` `delete` `delete[]` Память malloc освобождается при выходе из области видимости указателя без отдельного deleter

Вопрос 14 из 20

Как RAII-объект транзакции может реализовать откат?

Вызывать rollback только из catch пользователя Деструктор откатывает транзакцию без commit Удалять соединение вместо отката Всегда делать commit в деструкторе Не хранить состояние завершения

Вопрос 15 из 20

Почему владеющая обёртка должна запрещать копирование, если ресурс нельзя безопасно дублировать?

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

Вопрос 16 из 20

Почему RAII-обёртка ресурса должна быть перемещаемой, чтобы её можно было хранить в `std::vector`?

Vector требует operator< для всех хранимых типов RAII-обёртки нельзя хранить в стандартных контейнерах Перемещение нужно только для работы std::move явно, а push_back всегда копирует Vector всегда хранит объекты через shared_ptr и не требует перемещения При росте vector переносит элементы, а уникальный ресурс нельзя копировать, поэтому нужен move-конструктор

Вопрос 17 из 20

Какой риск есть у callback, захватившего `this`, если его сохранит внешний диспетчер?

class Window {
public:
    void start() {
        dispatcher_.post([this] { refresh(); });
    }
    ~Window() = default;
private:
    Dispatcher& dispatcher_;
};

Лямбда не сможет вызвать методы Callback может быть вызван после уничтожения объекта Захват this копирует весь объект Риск только в многопоточном коде Захват this создаёт shared_ptr на объект и удерживает его до уничтожения callback

Вопрос 18 из 20

Когда именно сработает очистка в RAII-объекте `Guard`, объявленном в начале функции?

Только если heavy_work бросила исключение При любом выходе из области видимости: раннем return, нормальном return и при исключении При первом обращении к переменной lock после её объявления Только при нормальном выходе из функции; ранний return обходит деструктор Деструктор Guard вызывается только явно через guard.release()

Вопрос 19 из 20

Какой дизайн безопаснее для фоновой задачи?

Передать в задачу ссылку на локальный объект и отсоединить поток, рассчитывая на быстрое завершение Хранить адрес локального массива в глобальной переменной Захватить ссылки на все локальные переменные и сразу выйти из функции Передать задаче владение либо дождаться её до разрушения данных Передать ссылки на локальные данные и рассчитывать, что задача завершится раньше выхода из функции

Вопрос 20 из 20

Можно ли использовать указатель, полученный из `file.get()` после уничтожения owner?

FILE* raw = nullptr;
{
    FileOwner owner = open_file();
    raw = owner.get();
}
// owner уже уничтожен

Да, пока числовое значение адреса не стало nullptr Да: get передаёт владение вызывающему коду, даже если owner уже уничтожен Нет: уничтожение владельца завершило жизнь объекта, и сырой указатель стал висячим Указатель остаётся действительным внутри потока, где был уничтожен owner Чтение допустимо после разрушения, а запись уже приводит к ошибке

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

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

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

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