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();

`std::unique_ptr<T>` `const T*` `std::shared_ptr<T>` всегда `std::weak_ptr<T>` `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));
}

p и параметр consume станут двумя независимыми владельцами одного int Владение перейдёт параметру consume, а p после вызова станет пустым Управляемый int уничтожится до входа в тело consume Значение будет скопировано, а p сохранит единственное владение Вызов потребует `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(const Widget* widget)` `void inspect(std::unique_ptr<Widget> widget)` `void inspect(Widget widget)` `void inspect(std::shared_ptr<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; // невладеющая, допускающая отсутствие связь
};

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

Вопрос 6 из 20

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

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

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

Вопрос 7 из 20

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

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

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

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

Вопрос 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);

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

Вопрос 14 из 20

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

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

Вопрос 15 из 20

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

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

Вопрос 16 из 20

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

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

Вопрос 17 из 20

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

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

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

Вопрос 18 из 20

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

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

Вопрос 19 из 20

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

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

Вопрос 20 из 20

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

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

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

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

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

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

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