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

Память и пользовательские аллокаторы

Тест отделяет выделение сырой памяти от времени жизни объекта. Вопросы охватывают new/delete, placement new, allocator_traits, memory_resource и фрагментацию — с упором на корректное построение, разрушение и измерение реальной пользы.

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

⏱ --:--

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

Вопрос 1 из 25

Что делает выражение `new T(args...)`?

void* raw = ::operator new(sizeof(Widget));
try {
    Widget* p = std::construct_at(static_cast<Widget*>(raw), config);
    use(*p);
} catch (...) {
    ::operator delete(raw);
    throw;
}

Строит временный T на стеке, а затем копирует его в заранее существующий буфер Вызывает лишь malloc-подобное выделение, не начиная время жизни T Сразу создаёт shared_ptr вместе с контрольным блоком Выделяет подходящее хранилище и затем конструирует в нём объект T Только обнуляет полученные байты, не вызывая конструктор T

Вопрос 2 из 25

Чем `::operator new(sizeof(T))` отличается от `new T`?

void* storage = ::operator new(sizeof(Widget)); // только сырая память
Widget* object = nullptr;
try {
    object = std::construct_at(static_cast<Widget*>(storage), 42);
} catch (...) {
    ::operator delete(storage);
    throw;
}

`::operator new(sizeof(T))` даёт сырое хранилище и не вызывает конструктор T Обе формы создают полноценный T и различаются только написанием При нехватке памяти `operator new` обязан вернуть nullptr, а выражение new — выбросить `operator new` всегда выделяет массив объектов T и хранит их количество `new T` лишь вызывает конструктор в уже переданном вызывающим кодом буфере

Вопрос 3 из 25

Почему `delete[]` обязан соответствовать `new[]`?

Widget* items = new Widget[4];
// ...
delete items;   // неверная парная форма
// delete[] items; // корректная форма

Различие только стилистическое delete сам определяет форму выделения по типу указателя new[] использует malloc, поэтому массив следует освобождать через std::free delete[] нужен лишь для char Нужно разрушить все элементы и совместимо освободить блок

Вопрос 4 из 25

Что произойдёт при обычном `new T` при нехватке памяти?

try {
    auto* block = new LargeTable(1'000'000);
    use(block);
    delete block;
} catch (const std::bad_alloc& error) {
    report_memory_pressure(error);
}

По умолчанию будет выброшено std::bad_alloc Будет вызван деструктор T Всегда вернётся nullptr Программа тихо продолжит с адресом 0 Создастся пустой T на стеке

Вопрос 5 из 25

Когда нужна alignment-aware форма allocation function?

struct alignas(64) CacheLine {
    std::byte bytes[64];
};
void* p = ::operator new(
    sizeof(CacheLine),
    std::align_val_t{alignof(CacheLine)}
);

Для любого int, если выделение выполняется внутри шаблонной функции Когда RTTI отключён и allocator не может узнать динамический тип Для типа, чьё требуемое выравнивание превышает стандартно поддерживаемое обычной формой allocation function Для любого const-объекта независимо от его alignof Для строкового объекта, потому что символы обязаны лежать на границе cache line

Вопрос 6 из 25

Что делает placement new `new (buffer) T(args...)`?

alignas(Widget) std::byte storage[sizeof(Widget)];

Widget* object = new (storage) Widget(42);
object->run();
object->~Widget();

Сначала освобождает прежний блок `buffer`, затем выделяет память для T Конструирует T по указанному адресу без выделения нового блока памяти Копирует содержимое `buffer` в новый объект T, выделенный обычным `new` Выделяет отдельный блок для T, используя `buffer` только как подсказку аллокатору Вызывает деструктор объекта, который ранее находился в `buffer`

Вопрос 7 из 25

Как завершить жизнь объекта, созданного placement new, без освобождения внешнего буфера?

alignas(Node) std::byte buffer[sizeof(Node)];
Node* node = std::construct_at(
    reinterpret_cast<Node*>(buffer), 7);

consume(*node);
std::destroy_at(node); // buffer остаётся внешним

Обнулить указатель: `ptr = nullptr`, после чего объект считается разрушенным Вызвать `std::destroy_at(ptr)` либо напрямую деструктор, не освобождая буфер Передать `ptr` в `std::free`, не вызывая деструктор объекта Оставить объект без разрушения, поскольку placement new не создаёт время жизни Вызвать `delete ptr`, чтобы одновременно разрушить объект и освободить внешний буфер

Вопрос 8 из 25

Что не так с кодом?

char buffer[sizeof(T)];
T* p = new (buffer) T;

Нужно вызвать malloc вместо массива buffer обязан быть const sizeof(T) допустим только для тривиальных типов, поэтому здесь нельзя вычислять размер хранения Буфер char может не иметь требуемого выравнивания для T placement new запрещён для классов

Вопрос 9 из 25

Когда может понадобиться std::launder?

alignas(Node) std::byte storage[sizeof(Node)];
Node* old = std::construct_at(
    reinterpret_cast<Node*>(storage), 1
);
std::destroy_at(old);
Node* current = std::construct_at(
    reinterpret_cast<Node*>(storage), 2
);
// вопрос: какой указатель допустимо использовать дальше?

После замены объекта в том же хранилище После любого new Чтобы очистить кэш процессора Перед каждым delete Для преобразования int в double

Вопрос 10 из 25

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

Widget widget;
widget.~Widget();
// конец области видимости позже попытается разрушить widget ещё раз

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

Вопрос 11 из 25

За что отвечает аллокатор контейнера?

Выделение и возврат сырой памяти элементов За сетевую сериализацию За виртуальную диспетчеризацию За бизнес-валидацию значений За сортировку элементов

Вопрос 12 из 25

Зачем использовать `std::allocator_traits<A>` вместо прямых вызовов методов A?

template<class Alloc>
void build_one(Alloc& alloc) {
    using Traits = std::allocator_traits<Alloc>;
    auto p = Traits::allocate(alloc, 1);
    try { Traits::construct(alloc, p, 42); }
    catch (...) { Traits::deallocate(alloc, p, 1); throw; }
}

Чтобы выбирать реализацию allocator по имени runtime-плагина Чтобы получить единый адаптированный интерфейс, типы и правила propagation для разных allocator Чтобы контейнер больше не выполнял выделений и хранил элементы только внутри себя Лишь для сокращения синтаксиса; семантика распространения allocator остаётся на контейнере Чтобы превратить пользовательский allocator в совместно владеющий указатель

Вопрос 13 из 25

Что даёт `std::pmr::vector<T>`?

std::array<std::byte, 4096> buffer{};
std::pmr::monotonic_buffer_resource arena(buffer.data(), buffer.size());
std::pmr::vector<Record> rows{&arena};

rows.reserve(100);
load(rows);

Vector с виртуальными элементами Распределяет элементы контейнера по NUMA-узлам без участия memory_resource Vector только для POD Контейнер без аллокаций Аллокатор с runtime-выбором memory_resource

Вопрос 14 из 25

Когда `std::pmr::monotonic_buffer_resource` особенно полезен?

void handle_request(const Request& request) {
    std::array<std::byte, 32 * 1024> storage{};
    std::pmr::monotonic_buffer_resource arena(storage.data(), storage.size());
    std::pmr::vector<Token> tokens{&arena};
    parse(request.body(), tokens);
} // вся арена освобождается одним действием

Когда нужно индивидуально возвращать каждый блок в ОС немедленно Чтобы получить упорядоченный map Для синхронизации потоков При пакетном создании и общем освобождении в конце фазы Когда данные живут вечно и растут без границ

Вопрос 15 из 25

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

Старый буфер нельзя освободить новым аллокатором Любое перемещение контейнера с пользовательским allocator сортирует элементы перед переносом Перемещающий контейнер обязан сохранить адрес старого буфера даже при смене allocator При несовпадающих аллокаторах перемещающий конструктор контейнера обязан копировать каждый элемент Аллокатор меняет тип элементов

Вопрос 16 из 25

Что такое внешняя фрагментация?

Размещение живых объектов рядом в одном последовательном буфере Наличие достаточного суммарного свободного объёма, разбитого на участки, слишком маленькие для крупного запроса Неиспользуемое место внутри каждого выделенного блока из-за округления размера Временное отсутствие нужной cache line в кэше процессора Часть виртуальной памяти, занятая исполняемым кодом и таблицами символов

Вопрос 17 из 25

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

Пул переиспользует однотипные блоки, сокращает общий путь выделения и часто улучшает локальность Каждое освобождение узла немедленно возвращает отдельный блок операционной системе Фиксированный размер сам по себе делает allocator корректным для параллельного доступа без синхронизации Один резерв делает доступную память практически неограниченной Пул пропускает вызов конструктора для каждого повторно используемого блока

Вопрос 18 из 25

Как уменьшить число мелких аллокаций для множества коротких строк?

Arena/pmr и пакетное хранение после измерения Поместить каждую строку в отдельный shared_ptr, не меняя стратегию размещения самих строк Вызывать new для каждого символа Хранить каждую строку в shared_ptr обязательно Заменить char на более широкий тип, чтобы одна аллокация вмещала меньше элементов

Вопрос 19 из 25

Почему compact vector объектов часто лучше vector<unique_ptr<T>> для однородных значений?

vector значений запрещает перемещение Указатели занимают ноль байт unique_ptr не компилируется в vector Меньше аллокаций и разыменований, лучше локальность кэша Объекты в vector всегда polymorphic

Вопрос 20 из 25

Может ли пользовательский аллокатор устранить утечку, вызванную потерянным владельцем?

Да, любой allocator является сборщиком мусора Да, если блок меньше 1 КБ Нет, потому что аллокаторы не освобождают память вообще Нет: аллокатор не исправляет потерю логического владельца Только linker может устранить утечку

Вопрос 21 из 25

Что обнаруживает AddressSanitizer?

Все гонки данных между потоками, включая логические ошибки атомарного протокола Фрагментацию кучи и причины высокой задержки конкретного allocator Любую утечку бизнес-объекта без обращения Выходы за границы и use-after-free Нарушение строгого слабого порядка

Вопрос 22 из 25

Как проверить, что пользовательский memory_resource получает правильное выравнивание?

Считать только число вызовов allocate, не анализируя переданный alignment и адрес результата Записывать запрошенный alignment и проверять кратность возвращённого адреса этому значению Отключить assertion выравнивания, чтобы тест не зависел от платформы Проверить адрес относительно `alignof(std::max_align_t)`, не учитывая большее выравнивание конкретного запроса Проверять каждый запрос относительно alignof(int), даже для over-aligned типов

Вопрос 23 из 25

Как измерить эффект monotonic_resource?

Измерить только компиляцию Проверить один пустой vector Сравнить только размер исходника Сравнить upstream-аллокации, время и пик памяти Считать любую экономию гарантированной

Вопрос 24 из 25

Какой тест нужен для exception safety ручного construct/deallocate?

Бросить в конструкторе и проверить полную очистку Проверить имя allocator Сделать тип trivially destructible Только успешное создание одного int Не вызывать деструкторы

Вопрос 25 из 25

Почему счётчик `operator new` на уровне процесса может вводить в заблуждение?

std::atomic<std::size_t> allocations{0};

void* operator new(std::size_t n) {
    allocations.fetch_add(1, std::memory_order_relaxed);
    if (void* p = std::malloc(n)) return p;
    throw std::bad_alloc{};
}
// Счётчик видит также библиотеки и внутренние аллокации инфраструктуры.

Глобальный operator new не вызывается ни одним стандартным контейнером Установка счётчика меняет тип и размер каждого выделяемого объекта Он объединяет запросы приложения, библиотек, внутренних пулов и кэшей, не показывая их назначение и время жизни Все аллокации имеют одинаковую стоимость, поэтому контекст вызова не нужен Число вызовов однозначно определяет время работы независимо от размеров и поведения allocator

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

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

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

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