Підсумки

Висновки

Ітератор відокремлює алгоритм від будови контейнера й задає позицію в напіввідкритому діапазоні, межу end якого не розіменовують. Категорія ітератора визначає доступні операції та їхню вартість, тому алгоритм вимагає лише потрібних йому можливостей. Зміна структури контейнера може зробити позиції недійсними за правилами конкретного контейнера. Алгоритм remove_if лише переставляє елементи, а фізичне скорочення виконує erase або std::erase_if. Лямбда є об’єктом замикання, у якому захоплення за значенням створює знімок, а захоплення за посиланням вимагає гарантії часу життя. Для пошуку, сортування та накопичення важливі передумови: строгий порядок компаратора, впорядкованість діапазону, достатнє місце призначення й правильний початковий тип. Ranges-алгоритми з проєкціями та подання дають лінивий конвеєр, у якому порядок адаптерів є частиною задачі. Подання позичає дані власника, тому для незалежного результату його матеріалізують у власний контейнер.

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

1. Чому end не можна розіменовувати?
2. Яку складність має distance для vector і list?
3. Чому reserve не створює елементи призначення copy?
4. Що залишається у хвості після remove_if?
5. Як копіювання mutable-лямбди впливає на її стан?
6. Чому std::function не подовжує життя позиченої змінної?
7. Яка передумова lower_bound?
8. Коли reduce може відрізнятися від accumulate?
9. Чому zip не перевіряє рівність довжин для задачі?
10. Як відрізнити матеріалізовані дані від позиченого view?

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

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