Підсумки

Висновки

Контейнер вибирають за операціями, ключами, потребою в порядку, дублікатах і стабільності елементів, а не за знайомою назвою. Позначення складності описує зростання кількості операцій і має передумови, тому фактичну вартість перевіряють відтворюваним експериментом. vector зберігає елементи неперервно й розрізняє size та capacity, а span лише позичає пам’ять власника. deque, list і forward_list мають інші гарантії доступу, вставки та чинності посилань і ітераторів. У set і map унікальність визначає еквівалентність компаратора, а методи доступу по-різному поводяться з відсутнім ключем. Хешовані контейнери потребують узгоджених рівності й хеша, допускають колізії та не гарантують порядку обходу. Адаптери навмисно звужують інтерфейс до правил LIFO, FIFO або пріоритету. Після кожної зміни структури варто перевіряти інваріанти даних, а не лише підсумковий звіт.

Питання для самоперевірки

1. Чим size відрізняється від capacity?
2. Чому span не подовжує час життя вектора?
3. Коли стала вставка у list не дає сталої вартості всієї операції?
4. Чим еквівалентність компаратора відрізняється від ==?
5. Які методи map можуть додати відсутній ключ?
6. Що означає колізія і чому вона допустима?
7. Який зв’язок між рівністю ключів і хеш-функцією?
8. Чим відрізняються гарантії ітератора та посилання після rehash?
9. Як забезпечити стабільну нічию у priority_queue?
10. Чому mdspan не слід називати контейнером-власником?

Контрольні питання до лабораторної роботи

1. Який інваріант забезпечує контейнер у вашому варіанті?
2. Чи потрібні дублікати та в якому сенсі ключі рівні?
3. Яка операція може зробити ваш ітератор недійсним?
4. Чи має виміряний час однакові умови для всіх контейнерів?
5. Як перевірено відсутній елемент?