C++ C++ · 25 вопросов · ~70 мин · ⏱ Таймер 10:00 · Средний ·

Умные указатели

Тест разбирает модели владения, а не просто названия классов. Вопросы проверяют передачу unique_ptr, устройство контрольного блока shared_ptr, безопасное наблюдение через weak_ptr и циклы, которые не видит обычный подсчёт ссылок.

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

⏱ --:--

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

Вопрос 1 из 25

Что верно после `auto q = std::move(p);`?

auto p = std::make_unique<int>(42);
auto q = std::move(p);

Объект скопирован q владеет объектом, p пуст Объект уже уничтожен Оба владеют объектом Код не компилируется

Вопрос 2 из 25

Чем `release()` отличается от `reset()`?

auto owner = std::make_unique<Resource>();
Resource* raw = owner.release(); // owner теперь пуст, raw надо освободить вручную

auto other = std::make_unique<Resource>();
other.reset();                  // объект уничтожен, other пуст

Обе запрещены для unique_ptr `release` отдаёт без удаления, `reset` удаляет release делает глубокую копию reset только возвращает адрес Обе функции удаляют объект

Вопрос 3 из 25

Как правильно создать unique_ptr для динамического массива из десяти int?

auto values = std::make_unique<int[]>(10);
for (std::size_t i = 0; i < 10; ++i)
    values[i] = static_cast<int>(i * i);

std::cout << values[9];

`auto p = std::make_unique<int[]>(10);` `std::unique_ptr<int> p(new int[10]);` без специального типа `auto p = std::make_shared<int[]>(10)` обязательно Обычный int* из new[] получает информацию о владельце и освобождается при выходе из области видимости `std::make_unique<int>(10)`

Вопрос 4 из 25

Когда пользовательский deleter становится частью типа unique_ptr?

struct CloseFile {
    void operator()(std::FILE* f) const noexcept {
        if (f) std::fclose(f);
    }
};
using FilePtr = std::unique_ptr<std::FILE, CloseFile>;

Только в специализации unique_ptr для массивов Только когда deleter хранит состояние и поэтому увеличивает размер объекта Только для deleter в виде указателя на функцию Лишь если deleter отличается от `std::default_delete<T>` во время выполнения Всегда: Deleter — второй параметр шаблона и часть статического типа unique_ptr

Вопрос 5 из 25

Какая сигнатура яснее всего принимает владение?

class Repository {
public:
    void set_cache(std::unique_ptr<Cache> cache) {
        cache_ = std::move(cache);
    }
private:
    std::unique_ptr<Cache> cache_;
};

`void set_child(Node* child)` без договора `void set_child(Node** child)` `void set_child(std::weak_ptr<Node>)` `void set_child(std::unique_ptr<Node> child)` `void set_child(const Node& child)`

Вопрос 6 из 25

Что хранит контрольный блок shared_ptr?

Только sizeof(T), нужный для вызова delete Таблицу виртуальных функций T, даже если T неполиморфный Сильный и слабый счётчики, deleter, allocator и другие служебные данные реализации Единый глобальный список всех shared_ptr процесса Сам объект T целиком внутри каждого экземпляра shared_ptr

Вопрос 7 из 25

Почему `std::make_shared<T>` часто эффективнее `std::shared_ptr<T>(new T)`?

auto a = std::shared_ptr<Node>(new Node(42));
auto b = std::make_shared<Node>(42);

// a обычно требует отдельного блока для Node и control block;
// b может объединить их.

Одна аллокация для объекта и control block make_shared запрещает изменение T после создания, поэтому контрольный блок получается меньше Позволяет копировать любой некопируемый T Не использует счётчики Всегда размещает T на стеке

Вопрос 8 из 25

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

T* raw = new T;
std::shared_ptr<T> a(raw);
std::shared_ptr<T> b(raw);

Ошибка проявляется только при передаче этих shared_ptr между потоками Оба конструктора находят контрольный блок по адресу и используют общий счётчик Второй shared_ptr превращает первый объект в невладеющий weak_ptr Второй конструктор распознаёт повторное владение и выбрасывает исключение Создаются два независимых контрольных блока, что ведёт к двойному удалению

Вопрос 9 из 25

Зачем нужен `std::enable_shared_from_this<T>`?

class Session : public std::enable_shared_from_this<Session> {
public:
    std::shared_ptr<Session> self() {
        return shared_from_this();
    }
};

auto session = std::make_shared<Session>();

Гарантировать, что объект можно создать только через `new`, но не через make_shared Хранить сильную ссылку на самого себя непосредственно внутри каждого объекта Создать новый независимый control block для `this` при каждом вызове self() Разрешить shared_from_this до появления первого shared_ptr-владельца Получить shared_ptr, связанный с уже существующим control block объекта

Вопрос 10 из 25

Что делает aliasing-конструктор shared_ptr?

Определён лишь для shared_ptr<T[]> и не применим к подобъектам Делит контрольный блок с владельцем, но хранит указатель на другой объект или подобъект Сразу уменьшает сильный счётчик владельца до нуля Создаёт глубокую копию подобъекта и отдельный владеющий shared_ptr Создаёт независимый контрольный блок для того же объекта

Вопрос 11 из 25

Продлевает ли weak_ptr жизнь объекта?

Нет Только при копировании weak_ptr Только если объект const Только пока существует контрольный блок, даже если сильных владельцев уже не осталось Да, как shared_ptr

Вопрос 12 из 25

Что возвращает `w.lock()`, если объект уже уничтожен?

std::weak_ptr<Session> weak;
{
    auto owner = std::make_shared<Session>();
    weak = owner;
}

auto locked = weak.lock();

Висячий сырой указатель Пустой shared_ptr Новый объект T Сам weak_ptr Исключение std::bad_alloc

Вопрос 13 из 25

Почему отдельная проверка `expired()` перед `lock()` недостаточна в многопоточном коде?

std::weak_ptr<Session> weak = registry.find(id);

if (!weak.expired()) {
    // Между проверкой и lock последний владелец может исчезнуть.
    auto owner = weak.lock();
    use(owner);
}

Копии weak_ptr нельзя читать из разных потоков, даже если сами объекты различны Expired уменьшает сильный счётчик и потому само может уничтожить объект Объект может исчезнуть между вызовами; только lock атомарно возвращает сильную ссылку или пустой результат После вызова expired стандарт запрещает обращаться к тому же weak_ptr через lock Expired остаётся false, пока жив сам объект weak_ptr, независимо от сильных владельцев

Вопрос 14 из 25

Какой тип поля подходит наблюдателю, который не должен владеть Subject, но Subject управляется shared_ptr?

class Observer {
public:
    explicit Observer(std::shared_ptr<Subject> subject)
        : subject_(subject) {}
    void poll() {
        if (auto subject = subject_.lock()) subject->read();
    }
private:
    std::weak_ptr<Subject> subject_;
};

Копия `Subject` по значению, не связанная с исходным объектом `std::unique_ptr<Subject>`, передающий Subject в собственность наблюдателя `std::shared_ptr<Subject>`, создающий сильную обратную связь и владение `std::weak_ptr<Subject>`, если Subject уже имеет внешних shared-владельцев Нетипизированный адрес без документации времени жизни и проверки типа

Вопрос 15 из 25

Что покажет проверка weak_ptr после выхода единственного владельца из блока?

#include <iostream>
#include <memory>
int main(){
    std::weak_ptr<int> w;
    { auto p = std::make_shared<int>(1); w = p; }
    std::cout << (w.lock() ? "alive" : "gone");
}

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

Вопрос 16 из 25

Почему два объекта с взаимными shared_ptr могут не разрушиться?

Каждый сохраняет сильный счётчик другого выше нуля Цикл разрешается сборщиком мусора При обнаружении цикла shared_ptr преобразует одну из сильных ссылок в weak_ptr shared_ptr не вызывает деструкторы вообще Проблема только при трёх объектах

Вопрос 17 из 25

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

Дети хранят weak_ptr или невладеющий указатель на родителя Хранить у ребёнка shared_ptr на родителя, чтобы обе стороны связи выглядели одинаково Родитель и ребёнок хранят shared_ptr друг на друга Каждый ребёнок владеет родителем unique_ptr Копируют родителя в ребёнка

Вопрос 18 из 25

Может ли callback, хранящий shared_ptr на владельца, образовать цикл?

Лишь если operator() callback объявлен виртуальным Первый вызов std::function автоматически очищает все захваты и разрывает связь Да: если владелец хранит callback, а callback сильной ссылкой захватывает владельца Лишь при захвате unique_ptr, потому что shared_ptr не создаёт циклов Нет: callable не участвует в графе владения захваченных объектов

Вопрос 19 из 25

Как исправить цикл в callback?

Захватить raw this и игнорировать срок жизни Сделать callback global Захватить weak_ptr и делать lock во время вызова Копировать весь объект по значению Вызвать delete this в callback

Вопрос 20 из 25

Почему нельзя механически заменить все shared_ptr в цикле на weak_ptr?

Должен остаться ясный сильный владелец Все weak_ptr участвуют в общем object pool, который сохраняет объект до завершения программы weak_ptr всегда владеет сильнее weak_ptr нельзя хранить в полях shared_ptr запрещён в графах

Вопрос 21 из 25

Почему `use_count() == 1` не стоит использовать как основу синхронизации?

std::shared_ptr<State> state = load_state();

if (state.use_count() == 1) {
    // Другой поток может получить копию shared_ptr сразу после проверки.
    mutate(*state);
}

Счётчик хранится отдельно от контрольного блока shared_ptr и не связан с владением Метод существует только у weak_ptr и не отражает сильных владельцев Use_count возвращает ноль, пока shared_ptr не был скопирован хотя бы один раз Вызов use_count уменьшает счётчик и при единице уничтожает объект Значение может измениться сразу после чтения и не даёт монопольного доступа к самому объекту

Вопрос 22 из 25

Как AddressSanitizer поможет при ошибочном создании двух контрольных блоков?

Никак: санитайзеры не видят память Найдёт double free или use-after-free ASan объединит два control block для одного адреса и продолжит выполнение без ошибки Исправит код в бинарнике Покажет только утечки файлов

Вопрос 23 из 25

Как проверить пользовательский deleter?

Проверить лишь компиляцию Проверить ровно один вызов deleter на всех путях Вызвать deleter вручную дважды Не разрушать объект в тесте Сравнить только sizeof указателя

Вопрос 24 из 25

Что сигнализирует о подозрительном shared_ptr в параметре `void draw(std::shared_ptr<const Shape>)`?

void draw(std::shared_ptr<const Shape> shape) {
    renderer.draw(*shape);
}

// Функция не сохраняет shape и не участвует в его владении.

Shared_ptr нельзя передавать по значению ни в одной функции чтения Const нельзя сочетать с shared_ptr на объект базового класса Если функция не сохраняет и не разделяет владение, `const Shape&` точнее и дешевле выражает контракт Передача shared_ptr создаёт глубокую копию Shape при каждом вызове draw Полиморфный параметр обязан передаваться через shared_ptr независимо от владения

Вопрос 25 из 25

Какой тест ловит цикл владения?

Снять use_count до построения связей и не проверять состояние после удаления корневых владельцев Оставить один корневой shared_ptr до конца теста и ожидать разрушения связанных объектов раньше него Удалить всех внешних сильных владельцев и проверить, были ли вызваны деструкторы и стал ли наблюдающий weak_ptr истёкшим Проверить только значения полей, не наблюдая завершение времени жизни объектов Сравнить адреса объектов до и после связывания: одинаковые адреса означают отсутствие цикла

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

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

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

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