Продуктивність і читабельність

1. Вступ

Коли ви вперше бачите ranges, хочеться негайно переписати все на пайплайни — приблизно як у перший день зі std::cout, коли кортить вивести на екран навіть температуру процесора. Але на практиці ranges — це інструмент, а не релігія. Іноді він робить код коротшим, яснішим і навіть швидшим без додаткових зусиль. А іноді ви отримуєте красиву однорядкову «поему», до якої навіть автор уже за два тижні боїться торкатися, і ще й неочікувані втрати продуктивності через повторні проходи.

Дуже важливо навчитися ставити собі дорослі запитання: «Цей пайплайн виконуватиметься один раз чи багато разів?», «Чи потрібен мені результат із володінням даними?», «Я точно не змінюватиму вихідний контейнер?», «Код читається зліва праворуч як рецепт чи радше як ребус на олімпіаді?».

Щоб говорити предметно, спиратимемося на наш навчальний мініпроєкт: консольний застосунок TaskBook (список задач). У нас є std::vector<Task>, ми вміємо друкувати задачі, шукати їх, сортувати тощо. Сьогодні додамо «вітрину»: покажемо перші N важливих незавершених задач, а далі обговоримо, коли це краще робити через view‑пайплайн, а коли — через матеріалізацію або звичайний цикл.

2. Вартість ranges: що майже безплатне, а що може «вжалити»

Пайплайни виглядають так, ніби ви зібрали конвеєр на заводі: на вході — контейнер, на виході — результат. Але ключовий нюанс у тому, що view — це найчастіше не фабрика, а креслення фабрики. Доки ви не пройдетеся діапазоном у циклі for, реальна робота може взагалі не початися. Звідси випливають і переваги, і пастки: можна уникнути зайвої роботи, але так само легко не помітити, що ви виконали її двічі.

Давайте зафіксуємо три найважливіші «ціни» ranges/views: кількість проходів, алокації й копії, а також властивості діапазону — наприклад, чи можна швидко дізнатися size() і чи є довільний доступ.

Лінивість: робота виконується під час обходу й може повторюватися

Лінивість — це чудово, доки ви свідомо робите один прохід. Але якщо ви обходите view двічі, то «лінивий конвеєр» відпрацює двічі. Іноді це нормально, а іноді ви випадково подвоюєте витрати.

Мініприклад із лічильником викликів (тут важливіша сама ідея, ніж конкретний проєкт):

#include <iostream>
#include <ranges>
#include <vector>

int main() {
    std::vector<int> v{1, 2, 3};
    int calls = 0;

    auto doubled = v | std::views::transform([&](int x) {
        ++calls;              // побічний ефект (підрахунок)
        return x * 2;
    });

    for (int x : doubled) { (void)x; }
    for (int x : doubled) { (void)x; }

    std::cout << calls << '\n'; // 6
}

Тут пайплайн видається нешкідливим, але два обходи дали 6 викликів лямбди. Якщо всередині transform у вас не ++calls, а, наприклад, важка функція — нормалізація рядка, обчислення хешу чи парсинг, — то «ой» стає цілком відчутним.

Практичний висновок простий: view‑пайплайн чудово підходить для сценаріїв «прочитати й вивести» або «прочитати й один раз зібрати». Якщо ж ви плануєте використовувати результат багаторазово, його часто краще матеріалізувати.

Алокації та копії: view виграє, доки не потрібно зберігати результат

Коли ви пишете filter/transform/take, то зазвичай не створюєте новий std::vector і не робите push_back для кожного елемента. Це означає: менше алокацій, менше копій, часто й менше коду.

Але щойно вам потрібно зберегти результат, передати його кудись далі або повернутися до нього пізніше, ви все одно прийдете до контейнера. І от тоді постають запитання: скільки елементів буде, чи потрібен reserve, чи не копіюємо ми std::string даремно тощо.

Гарне правило: view‑пайплайн — це про обробку на льоту, а матеріалізація — про стабілізацію даних.

Втрата зручних властивостей: filter може позбавити size() та індексів

Контейнер на кшталт std::vector чудовий тим, що має швидкий довільний доступ і зрозумілий size(). Але після std::views::filter ви отримуєте «відфільтровану послідовність», і вона вже може не поводитися як std::vector: наприклад, наперед невідомо, скільки елементів пройде фільтр, а іноді не можна ефективно звернутися до елемента за індексом.

Це не «погано», це просто інша модель. Не варто очікувати від view того, чого зазвичай очікують від контейнера.

Якщо ви пишете код, для якого принципово важливі size() та індекси, то або тримайтеся контейнерів, або матеріалізуйте результат на межі в контейнер, або переосмисліть задачу так, щоб одного проходу було достатньо.

3. Читабельність: пайплайн як рецепт, а не як заклинання

Продуктивність — це важливо, але програмісти-початківці частіше спотикаються не на наносекундах, а на підтримуваності. Якщо ви самі не можете швидко зрозуміти, що робить код, то з часом почнете «оптимізувати» його молотком.

ranges особливо легко перетворити на «красиво, але незрозуміло», бо оператор | дуже спокушає написати простирадло «в один рядок». Тому сьогодні найважливіше зрозуміти: як писати пайплайни так, щоб вони справді поліпшували читабельність.

Довжина пайплайна: 1–3 кроки зазвичай легко, 6–8 — уже важко

Пайплайн добрий, коли його буквально можна промовити вголос. Наприклад: «беремо задачі → залишаємо незавершені → беремо перші 3». Це й справді схоже на рецепт.

Коли кроків стає багато, особливо з вкладеними лямбдами, мозок перестає втримувати все одразу. Тоді виграє підхід «дати імена проміжним крокам».

Порівняймо дві форми.

Варіант «простирадло» (на прикладі задач — код умовний, важливіший за нього сам сенс):

auto view = tasks
    | std::views::filter([](const Task& t){ return !t.done; })
    | std::views::filter([](const Task& t){ return t.priority >= 5; })
    | std::views::transform([](const Task& t){ return t.title; })
    | std::views::take(3);

Це ще терпимо, але вже на межі: два фільтри поспіль і ще transform.

Варіант «кроки з іменами»:

auto pending = tasks | std::views::filter([](const Task& t) { return !t.done; });
auto urgent  = pending | std::views::filter([](const Task& t) { return t.priority >= 5; });
auto titles  = urgent  | std::views::transform([](const Task& t) { return t.title; });
auto top3    = titles  | std::views::take(3);

Так, рядків більше. Зате кожен рядок передає одну невелику думку, яку легко перевірити очима. І це критично, коли ви налагоджуєте код, обговорюєте його під час код-ревʼю або коли ваш майбутній ви намагається зрозуміти, чому «показуються не ті три задачі».

Лямбди: тримайте їх короткими та «чистими»

Лямбда всередині filter — це предикат. Усередині transform — перетворення. Ідеальний варіант: вони не мають побічних ефектів і не змінюють зовнішні змінні.

Якщо ви робите побічний ефект — друк, інкремент лічильника чи запис у файл, — то маєте памʼятати: view лінивий, і цей ефект відбудеться під час обходу. Двічі пройшлися — двічі надрукували. Це не баг, а чесна семантика.

Якщо вам обовʼязково потрібен побічний ефект, іноді чесніше написати звичайний цикл, тому що цикл уже самим виглядом обіцяє виконання тут і зараз, а view — ні.

auto допомагає читабельності, бо типи для views «страшні»

Типи обʼєктів, які повертають std::views::filter та std::views::transform, довгі й залежать від того, які саме лямбди ви передали. Намагатися писати їх вручну — майже гарантований спосіб зіпсувати собі день.

Тому в коді з ranges auto — це не «ховаємо тип від читача», а «не змушуємо читача дивитися на три екрани шаблонної каші». Читач має бачити сенс: pending, urgent, top3. Це як змінні sum і count: вони важливіші за точний тип обʼєкта.

4. Коли ranges/views справді пришвидшують код

Є сценарії, у яких ranges одночасно виграють і за читабельністю, і за продуктивністю. Зазвичай це сценарії «один прохід, мінімум памʼяті, рання зупинка».

Нижче — таблиця, яку корисно тримати в голові. Це не «закон», а радше орієнтир:

views::filter + range-for

views::transform + range-for

filter + take

view-пайплайн

матеріалізація

Саме «filter + take» часто дає приємний бонус: вам не потрібно проходити весь контейнер, якщо потрібні лише перші 3 відповідні елементи. Вручну цього теж можна досягти, але ranges дозволяє записати таку логіку дуже декларативно.

5. Коли ranges/views ускладнюють код і можуть уповільнювати

Є й протилежні сценарії. У них ranges лишаються робочим інструментом, але ціна цієї краси стає надто високою: або за продуктивністю — через повторні обчислення, або за підтримуваністю — через надто складний пайплайн, або за безпекою — через час життя й інвалідацію, або просто за налагодженням.

Важливо: мета не в тому, щоб «уникати ranges», а в тому, щоб розуміти, коли варто зупинитися й зробити код простішим.

Повторне використання результату: view не кешує

Якщо ви будуєте view, а потім використовуєте його в трьох місцях — порахували статистику, далі вивели, а потім зробили ще щось, — ви можете не помітити, що виконали три повні проходи й тричі викликали transform.

Якщо дані маленькі — нічого страшного. Якщо дані великі, це вже може стати відчутним.

У таких випадках матеріалізація часто робить код і швидшим, і зрозумілішим: «ось ми зібрали список важливих задач і тепер працюємо з ним».

Пайплайн із «розумною» логікою всередині лямбди

Якщо всередині filter у вас 15 рядків умов, кілька тимчасових змінних і ще звернення до зовнішніх структур, то це вже не «функціональний стиль», а звичайний код, захований усередині лямбди. Читабельність від цього зазвичай лише погіршується.

Часто краще винести умову в окрему функцію з промовистою назвою. Тоді пайплайн лишається декларативним: filter(IsUrgentTask) замість «ось вам пів блока умов просто в місці використання».

Межі даних і час життя: красивий view, який небезпечно зберігати

Ми це докладно розбирали в лекції про dangling: view живе поверх джерела. Якщо ви повертаєте view з функції, а джерело було локальним, то майже напевно повернете «представлення» на обʼєкт, якого вже не існує.

Навіть якщо компілятор вас не зупинить, це згодом зробить звіт про помилку.

6. Практика: «топ‑3» термінових незавершених задач

Тепер розгляньмо це на практиці: у нас є задачі, і ми хочемо вивести перші 3 задачі, які ще не виконані і мають пріоритет не нижче за заданий.

Спочатку зафіксуймо модель і простий друк. (Припускаємо, що Task і tasks у вас уже є з попередніх лекцій про struct, vector, функції та друк.)

Модель Task

Щоб приклади були зрозумілими, ось мінімальна модель:

#include <string>

struct Task {
    int id = 0;
    std::string title;
    bool done = false;
    int priority = 0;
};

View‑пайплайн «одразу на виведення»

Цей варіант добрий, коли нам потрібно просто один раз вивести результат.

#include <iostream>
#include <ranges>
#include <vector>

int main() {
    std::vector<Task> tasks{{1,"Read C++",false,7},{2,"Sleep",true,10},{3,"Debug",false,6}};

    auto top = tasks
        | std::views::filter([](const Task& t) { return !t.done; })
        | std::views::filter([](const Task& t) { return t.priority >= 6; })
        | std::views::take(3);

    for (const Task& t : top) std::cout << t.id << ": " << t.title << '\n';
    // 1: Read C++
    // 3: Debug
}

Тут пайплайн читається по-людськи: «незавершені → достатньо важливі → перші три». І він не створює нового контейнера.

Зауважте, що take(3) не означає «візьми три перші елементи вихідного вектора». Воно означає «візьми три перші елементи після фільтрів». Якщо відповідних задач дві, то їх і буде дві.

Ті самі кроки, але з іменами

Якщо пайплайн починає розростатися, імена допомагають.

#include <ranges>
#include <vector>

auto PendingTasks(const std::vector<Task>& tasks) {
    return tasks | std::views::filter([](const Task& t) { return !t.done; });
}

Цей приклад навмисно короткий, щоб показати ідею: view можна збирати з функцій. Але тут є тонкість: ми повертаємо view, який посилається на tasks. Це безпечно лише тоді, коли код, що викликає функцію, гарантує, що tasks житиме довше за результат. Усередині main зазвичай так і є. Якщо ви почнете передавати такий view далі, згадайте лекцію про час життя.

Коли матеріалізація виграє: використовуємо результат двічі

Уявімо, що ми хочемо і вивести «топ‑3», і порахувати, скільки серед них задач із пріоритетом 10. Якщо ми двічі обходитимемо один і той самий view, то двічі виконаємо умови filter.

Іноді це дрібниця, але покажімо більш «дорослий» варіант: зібрати результат в окремий std::vector<Task>.

#include <algorithm>
#include <iterator>
#include <ranges>
#include <vector>

int main() {
    std::vector<Task> tasks{{1,"Read C++",false,7},{2,"Sleep",true,10},{3,"Debug",false,6}};

    auto view = tasks
        | std::views::filter([](const Task& t) { return !t.done; })
        | std::views::filter([](const Task& t) { return t.priority >= 6; })
        | std::views::take(3);

    std::vector<Task> top;
    std::ranges::copy(view, std::back_inserter(top));
}

Тепер top — це повноцінний результат, яким ви володієте. Ви можете сортувати його, друкувати, рахувати статистику, передавати в інші функції — і не перейматися тим, що під час повторного використання фільтри знову виконуватимуться.

Так, ви заплатили копіями Task (а отже, і копіями std::string усередині title). Тому матеріалізація має бути усвідомленою: вона потрібна тоді, коли ви справді використовуєте результат далі, а не робите це «за звичкою».

Мінісхема вибору: view чи контейнер

Іноді корисно тримати в голові просту блок-схему, щоб не вагатися над кожним рядком коду. Зараз вона буде максимально прикладною й без зайвої філософії.

flowchart TD
    A[Потрібно отримати підмножину або перетворення даних] --> B{Результат потрібен лише один раз?}
    B -->|Так| C{Потрібно зберегти результат?}
    C -->|Ні| D[Views + range-for/алгоритм]
    C -->|Так| E[Матеріалізація в контейнер]
    B -->|Ні, використовуватимете багаторазово| E
    D --> F{Є ризик проблем із часом життя або інвалідацією джерела?}
    F -->|Так| E
    F -->|Ні| G[Залишаємо view]

Ця схема спеціально проста: вона не намагається замінити мислення, але допомагає не забути про дві головні причини матеріалізації — багаторазове використання та безпеку часу життя.

7. Типові помилки під час вибору між ranges/views і «звичайним» кодом

Помилка № 1: вважати, що view «обчислюється один раз і все запамʼятовує».
Початківці часто сприймають auto x = v | views::transform(...) як «я створив новий набір даних». Насправді це лише опис обчислення. Якщо потім ви двічі обходите x, то двічі виконуються filter/transform. Якщо всередині відбувається важка робота, ви раптово отримуєте уповільнення «наче на рівному місці».

Помилка № 2: робити побічні ефекти всередині filter/transform і дивуватися «дивній поведінці».
Якщо в transform ви щось друкуєте або змінюєте зовнішню змінну, то жорстко привʼязуєте коректність до кількості обходів. Один зайвий for — і логіка ламається. У таких випадках або робіть лямбди «чистими», або чесно використовуйте звичайний цикл, де виконання очевидне.

Помилка № 3: будувати гігантський пайплайн одним рядком і називати це «красою».
Пайплайн добрий, доки читається зліва праворуч як рецепт. Коли у вас пʼять адаптерів, складні лямбди й ще десь збоку take, це перетворюється на ребус. Зазвичай рятує розбиття на іменовані кроки: pending, urgent, top3.

Помилка № 4: матеріалізувати завжди й усюди «про запас».
Друга крайність після «все через views» — «все в новий vector». Тоді ви втрачаєте головну перевагу ranges: обробку на льоту без зайвих витрат памʼяті. Матеріалізуйте з причини: потрібне володіння, багаторазове використання, межа API, безпека часу життя.

Помилка № 5: забувати, що джерело view може змінитися або бути інвалідованим.
Навіть якщо tasks_view виглядає як окремий обʼєкт, він залежить від std::vector<Task> tasks. Якщо ви змінюєте tasks структурно — наприклад, через push_back або erase, — а потім обходите view, можна отримати неприємності. Це не «містика ranges», а звичайні правила часу життя та інвалідації, просто в новій обгортці.

1

Опитування

ranges/views, рівень 62, лекція 4

Недоступний

ranges/views

ranges/views

Відкрити