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

Стандартные контейнеры

Тест учит выбирать контейнер по реальному профилю операций, а не по привычке. Вопросы сопоставляют стоимость вставки, локальность данных, стабильность адресов, семантику ключей и поведение при перераспределении.

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

⏱ --:--

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

Вопрос 1 из 20

Что гарантирует std::vector о размещении элементов?

std::vector<int> values{10, 20, 30};
int* first = values.data();
static_assert(std::contiguous_iterator<decltype(values.begin())>);

Вставка в начало выполняется за постоянное время без перемещения элементов Каждый элемент получает отдельную динамическую аллокацию, связанную с предыдущим Элементы одного vector хранятся в непрерывном участке памяти Контейнер хранит только указатели, а сами значения всегда размещает отдельно Адрес существующего элемента сохраняется после любого роста vector

Вопрос 2 из 20

Чем reserve(100) отличается от resize(100)?

std::vector<Record> rows;
rows.reserve(100);   // size остаётся 0
rows.resize(100);    // создаются 100 элементов

Reserve запрашивает ёмкость без изменения числа элементов, resize меняет size Reserve уменьшает size до указанного значения, удаляя лишние элементы Обе операции создают сто default-элементов и устанавливают одинаковый size Resize меняет только capacity и не создаёт или не удаляет элементы Reserve переставляет элементы по возрастанию, чтобы освободить непрерывный запас

Вопрос 3 из 20

Что стандарт C++ гарантирует после вызова `v.reserve(10)`?

#include <vector>

std::vector<int> v{1, 2, 3};
v.reserve(10);

`v.size() == 0`, а `v.capacity() >= 10` `v.size() == 3` и `v.capacity() == 3`, потому что reserve носит лишь рекомендательный характер `v.size() == 3` и обязательно `v.capacity() == 10` `v.size() == 10` и `v.capacity() == 10` `v.size() == 3`, а `v.capacity() >= 10`

Вопрос 4 из 20

Почему вставка в середину vector может быть дорогой?

std::vector<Large> items = load();
auto pos = items.begin() + items.size() / 2;
items.insert(pos, Large{/*...*/});

Все элементы хранятся в связном списке Потому что size вычисляется линейно vector ищет элемент по хешу Вставка всегда требует сортировки Сдвиг элементов и возможное перераспределение буфера

Вопрос 5 из 20

Как лучше заполнить vector заранее известным числом элементов через push_back?

Вызывать clear после каждой вставки Использовать shrink_to_fit перед каждым push_back Вызвать reserve для ожидаемого количества, затем push_back Хранить элементы в глобальном массиве Вызвать resize и всё равно push_back то же количество

Вопрос 6 из 20

В какой задаче deque естественнее vector?

Передача всего буфера как одного массива C Поддержание отсортированного дерева Максимально компактное непрерывное хранение Поиск по ключу за среднее O(1) Частые добавления и удаления и в начале, и в конце

Вопрос 7 из 20

Можно ли рассчитывать, что `&d[0] + 1 == &d[1]` для deque?

std::deque<int> values{1,2,3};

int* first = &values[0];
int* second = &values[1];

bool adjacent_as_array = (first + 1 == second);

Нет: соседние логические элементы deque могут находиться в разных внутренних блоках Да, если элементы одинакового размера; тип не влияет на разбивку deque на блоки Равенство гарантируется после достижения некоторого размера блока реализации Да после reserve, потому что deque имеет тот же интерфейс управления ёмкостью, что vector Да: deque по контракту является одним непрерывным массивом, растущим с двух сторон

Вопрос 8 из 20

Какова сложность добавления элемента в начало std::deque через push_front?

Амортизированная O(1), как у push_back для vector O(log n), потому что deque хранит дерево блоков O(1) по требованиям контейнера O(n), потому что все элементы сдвигаются на одну позицию Зависит только от размера типа элемента и не имеет асимптотической оценки

Вопрос 9 из 20

Какой контейнер удобен для очереди задач, если нужны pop_front и push_back?

std::deque std::array фиксированного размера без кольцевой логики std::vector с удалением первого элемента через erase(begin()) std::forward_list с поиском хвоста каждый раз std::priority_queue, если порядок поступления задач требуется сохранить точно

Вопрос 10 из 20

Какое утверждение о `std::queue` верно?

std::queue<Task> tasks;
tasks.push(load_task());

Task next = std::move(tasks.front());
tasks.pop();
// Произвольного доступа и обхода итераторами адаптер не предоставляет.

Адаптер предоставляет operator[] базового deque, если контейнер по умолчанию не заменён Он всегда хранит элементы непрерывно Это отдельное сбалансированное дерево Адаптер, обычно поверх deque Он сортирует элементы по приоритету

Вопрос 11 из 20

Какое преимущество std::list действительно гарантирует?

O(1) вставка/удаление по известному итератору Поиск позиции и вставка в неё всегда вместе занимают O(1) Поиск значения за O(1) Минимальный расход памяти на элемент Переход к элементу по индексу выполняется за O(1), поскольку узлы двусвязные

Вопрос 12 из 20

Почему list часто медленнее vector при простом последовательном обходе?

Плохая локальность узлов и лишние разыменования vector требует дополнительного разыменования для каждого элемента, а list хранит значения прямо в массиве Обход list имеет сложность O(n²) list каждый раз сортирует данные list хранит элементы в сжатом виде

Вопрос 13 из 20

Что делает `a.splice(a.end(), b, b.begin())`?

#include <list>
std::list<int> a{1,2};
std::list<int> b{3,4};
a.splice(a.end(), b, b.begin());

Переносит узел, на который указывает `b.begin()`, в конец a без копирования элемента Операция допустима лишь когда a и b пусты до вызова Сортирует оба списка перед объединением их диапазонов Копирует все элементы b в a, сохраняя исходный b неизменным Освобождает оба списка после перемещения единственного элемента

Вопрос 14 из 20

Какой итератор инвалидируется при `list.erase(it)`?

std::list<int> values{1,2,3,4};
auto first = values.begin();
auto erased = std::next(first, 2);
auto last = std::prev(values.end());

values.erase(erased);
std::cout << *first << ' ' << *last;

Итераторы всех контейнеров, использующих тот же аллокатор Только `begin()`, если удаляется не первый элемент списка Все итераторы и ссылки списка, поскольку меняется его размер Только итераторы и ссылки на удаляемый элемент Ни один итератор, включая `it`, потому что узлы list стабильны

Вопрос 15 из 20

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

Когда для каждой вставки уже есть точный итератор, а элементы очень дороги для перемещения Когда нужна гарантированная вставка за O(1) независимо от позиции Когда элементов немного или изменения выполняются пакетно, а плотное хранение и быстрый обход важнее стоимости сдвигов Когда требуется сохранять действительными все итераторы после каждой вставки Когда адрес каждого элемента должен оставаться неизменным до его удаления

Вопрос 16 из 20

Главное различие map и unordered_map?

map использует хеширование с упорядоченными корзинами, а unordered_map — сбалансированное дерево map хранит дубликаты ключей map упорядочен, unordered_map хеширован unordered_map допускает только целые ключи unordered_map является вектором

Вопрос 17 из 20

Что делает `m[key]`, если key отсутствует в std::map?

std::map<std::string, int> counts;

int& value = counts["errors"];
value += 1;

std::cout << counts.size() << ' ' << counts.at("errors");

Возвращает ссылку на ближайший существующий элемент по порядку ключей, не вставляя новый Возвращает nullptr без изменения map Удаляет ближайший ключ Всегда выбрасывает out_of_range Вставляет default-значение и возвращает ссылку

Вопрос 18 из 20

Как проверить наличие ключа без случайной вставки?

std::map<std::string, Config> configs;

if (configs.contains("prod")) use(configs.at("prod"));
if (auto it = configs.find("test"); it != configs.end()) use(it->second);
// Ни contains, ни find не вставляют отсутствующий ключ.

Прочитать `m[key]` и считать нулевое значение признаком отсутствия Вызвать `push_back(key)`, не меняя содержимое ассоциативного контейнера Передать ключ в `size(key)`, чтобы получить число совпадений Сравнить результат `lower_bound(key)` с `nullptr` Использовать `contains(key)` или сравнить `find(key)` с `end()`

Вопрос 19 из 20

Почему плохая хеш-функция опасна для unordered_map?

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

Вопрос 20 из 20

Какой контейнер удобнее для запроса “первый ключ не меньше x”?

std::unordered_map std::vector с сохранением элементов в порядке их поступления без дополнительной сортировки std::vector без сортировки std::priority_queue, вершина которой всегда считается первым ключом не меньше x std::map с lower_bound

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

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

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

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