Навіщо потрібні concepts

1. «Універсальні» шаблони майже завжди не універсальні

Коли ви вперше бачите шаблон, виникає цілком природна думка: «О, круто! Це функція „для будь-якого типу“». І справді, на рівні синтаксису все саме так і виглядає: template <typename T> ніби обіцяє працювати з усім, що компілюється. Але на практиці шаблон майже завжди спирається на конкретні операції: десь потрібен +, десь size(), десь begin()/end(). Якщо тип цього не вміє, компілятор падає — часто гучно й багатослівно.

Уявімо, що в нашому навчальному застосунку «Облік витрат» ми зберігаємо операції:

#include <string>

struct Transaction {
    std::string title;
    int cents = 0;
};

І нам захотілося написати «універсальну» функцію додавання, щоб підсумовувати int, double і взагалі що завгодно… ну, майже:

template <typename T>
T add(T a, T b) {
    return a + b; // прихована вимога: T має підтримувати operator+
}

З int усе чудово:

#include <iostream>

int main() {
    std::cout << add(10, 20) << '\n'; // 30
}

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

int main() {
    Transaction a{"coffee", 250};
    Transaction b{"sandwich", 500};

    // std::cout << add(a, b) << '\n'; // помилка компіляції
}

І тут зʼясовується неприємна річ: шаблон не «для будь-якого типу», а «для будь-якого типу, який підтримує a + b». Просто цієї фрази немає в коді — вона захована всередині тіла функції. Наче кіт, який «точно не їв рибу», але чомусь пахне рибою.

2. Чому помилки шаблонів виглядають як «простирадло з пекла»

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

Візьмімо ще ближчий до життя приклад. Ми пишемо функцію, яка повертає «довжину» обʼєкта. Для std::string або std::vector це очевидно: через size().

#include <cstddef>

template <typename T>
std::size_t len(const T& x) {
    return x.size(); // прихована вимога: T має мати метод size()
}

І це працює:

#include <iostream>
#include <string>

int main() {
    std::string s = "hello";
    std::cout << len(s) << '\n'; // 5
}

Але одного разу ми випадково викликаємо len(10). І компілятор замість дружнього «у int немає size()» часто видає щось на кшталт: «не існує відповідного кандидата», «помилка під час підстановки», «in instantiation of…» і так далі. Для досвідченого розробника це звична річ: він уміє вихопити головне. Для новачка це відчувається так, ніби ви відкрили чат із давнім богом компіляції — і він незадоволений.

Ключова проблема тут не в тому, що компілятор шкідливий. Проблема в тому, що вимога до типу не є частиною інтерфейсу функції. Ми бачимо template <typename T>, а мозок читає це як «будь-який тип», хоча насправді контракт значно вужчий.

3. Constraints і concepts: ідея та ефект

Що таке constraints за змістом

Concepts і constraints зʼявилися в C++ не для того, щоб зробити мову «ще більш C++». Ні, це вже, здається, неможливо: C++ і так максимально C++ (вибачте). Вони зʼявилися, щоб шаблонний код став чеснішим і дружнішим: вимоги до типів можна описати просто в оголошенні, а не ховати всередині тіла й чекати вибуху в момент використання.

Якщо пояснювати просто, constraint — це фільтр на етапі компіляції. Він каже: «Ця функція існує не для всіх T, а лише для тих T, які задовольняють умову». Важливий момент: це не if і не перевірка під час виконання. Якщо тип не підходить, програма навіть не збереться — і це добре, бо помилка зʼявляється ближче до місця виклику й формулюється зрозуміліше.

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

«Краще помилка раніше»: як concepts поліпшують діагностику компіляції

Головний практичний виграш від concepts — не краса синтаксису, хоча вона теж приємна. Найважливіше — якість помилок і читабельність інтерфейсу. Тобто ви відкриваєте заголовок і одразу бачите: «ця функція очікує цілочисельний тип» або «ця функція працює лише з контейнерами». І якщо ви помилилися, компілятор каже: «тип не задовольняє вимогу», замість того щоб кричати: «а-а-а, десь глибоко всередині у вас не знайшовся operator+».

Порівняймо це в невеликій таблиці — не для формальності, а щоб мозок краще вловив різницю:

Тепер — важлива тонкість. Constraints не роблять шаблон «магічно правильним». Якщо ви неправильно сформулювали вимогу, компілятор чесно її дотримуватиметься й може заборонити нормальні випадки або, навпаки, пропустити неправильні. Але це вже робота на рівні дизайну API, а не «боротьба з простирадлом помилок».

Мініісторія: «Узагальнили — і наступили собі на ногу»

Уявімо, що наш застосунок «Облік витрат» друкує звіт і підсумовує значення. Нехай у нас є суми в центах (int), але пізніше ми додали податки або конвертацію валют, і зʼявилися double. Ми вирішили написати шаблонну функцію підсумовування:

#include <vector>

template <typename T>
T sum2(const std::vector<T>& v) {
    T result{};              // прихована вимога: T має мати «нульове» значення
    for (const T& x : v) {
        result = result + x; // прихована вимога: потрібен operator+
    }
    return result;
}

Для чисел усе працює:

#include <iostream>
#include <vector>

int main() {
    std::vector<int> a{10, 20, 30};
    std::cout << sum2(a) << '\n'; // 60
}

А потім ми захотіли «підсумовувати операції», бо… ну… чому б і ні. Саме так зазвичай і народжуються баги:

int main() {
    std::vector<Transaction> ops{
        {"coffee", 250},
        {"sandwich", 500},
    };

    // auto total = sum2(ops); // помилка: Transaction не додається
}

І ось тут досвідчений розробник скаже: «Так і має бути, Transaction — не число». А новачок скаже: «Але ж я написав template, отже, це має бути універсально…» Саме для таких ситуацій і потрібні concepts: щоб шаблон одразу казав правду, а помилка звучала в стилі «функція sum2 призначена для числових типів», а не «десь на 123-му рядку інстанціювання у вас щось не склалося».

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

Constraints — це не перевірка під час виконання

Дуже легко переплутати constraints зі звичайними перевірками if. Тож скажімо це прямо: constraint живе у світі компілятора. Він визначає, чи існує для даного типу перевантаження або шаблон. Якщо тип не підходить, код навіть не доходить до стадії виконання. Жодної гілки else, жодної помилки під час виконання. Програма просто не збирається.

Щоб відчути різницю, уявіть дві ситуації. У першій ви пишете звичайну функцію й перевіряєте умови всередині:

int divide(int a, int b) {
    if (b == 0) {
        return 0; // погано, але для прикладу підійде
    }
    return a / b;
}

Це світ виконання: компіляція пройде, а коректність залежатиме від значень a і b.

У другій ситуації проблема не в значеннях, а в самому типі. Наприклад, ви хочете, щоб «ділення» існувало лише для числових типів. Тоді перевіряти це if безглуздо: тип не число — і все. Такий «контракт за типом» і є типовою сферою застосування concepts.

Це можна зобразити маленькою блок-схемою:

flowchart TD
    A[Ви написали шаблон] --> B[Хтось викликав його з типом T]
    B --> C{T відповідає контракту?}
    C -- ні --> D[Помилка компіляції поруч із місцем виклику]
    C -- так --> E[Інстанціювання шаблону]
    E --> F[Компіляція тіла]
    F --> G[Лінкування й запуск]

Без constraints компілятор частіше змушений іти правою гілкою, тобто інстанціювати шаблон, а вже потім «вибухати» в тілі. З constraints невідповідні типи можна відсіяти раніше.

Чому concepts важливі саме новачкам

Є стереотип: concepts — це «штука для людей, які пишуть std::vector 2.0». На практиці concepts дуже корисні і в прикладному коді, особливо в навчальному й командному. І ось три причини.

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

Друга причина — діагностика. Новачок помиляється частіше не тому, що він «поганий», а тому, що в нього поки немає внутрішньої картини мови. Довгі шаблонні помилки таку картину не будують — вони лише лякають. Коли помилка формулюється як «тип не задовольняє вимогу», у студента зʼявляється шанс: він розуміє, що потрібно не «лагодити компілятор», а підібрати правильний тип або правильну функцію.

Третя причина — дизайн вашого власного коду. Щойно ви починаєте писати бодай трохи узагальнені функції, а ми це вже робимо, у вас зʼявляється відповідальність: або писати в коментарях «T має мати size()», або фіксувати це в коді. Коментарі — це побажання. Concepts — це контракт.

4. Мікроприклади, де concepts бережуть нерви

Зараз буде кілька коротких прикладів. Вони спеціально маленькі — 5–10 рядків, — щоб ви побачили ідею, а не втонули в деталях. Синтаксис ми глибоко розбирати не будемо. Нам достатньо побачити сам ефект: «вимога стає явною».

Приклад A: функція «для контейнерів», а не «для чого завгодно»

Ми хочемо надрукувати кількість елементів. Логіка використовує size(), отже, це не «будь-який тип»:

#include <cstddef>

template <typename T>
std::size_t count_items(const T& x) {
    return x.size(); // якщо x не має size(), усе зламається
}

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

Приклад B: функція «для чисел», а не «для рядків»

Ми хочемо порахувати «квадрат». Не кожен тип уміє x * x:

template <typename T>
T square(T x) {
    return x * x; // потрібен operator*
}

Якщо хтось спробує square(std::string{"hi"}), помилка теж буде не надто дружньою. А з constraints можна зробити так, щоб «квадрат» застосовувався лише там, де це справді має сенс.

Приклад C: зрозуміла помилка замість «роману компіляції»

Ще до concepts ми могли поліпшувати повідомлення за допомогою static_assert. І це важливо памʼятати: concepts — не єдиний інструмент, але дуже хороший.

#include <concepts>

template <typename T>
T safe_square(T x) {
    static_assert(std::integral<T> || std::floating_point<T>,
                  "safe_square<T>: T має бути числовим типом");
    return x * x;
}

Тут ідея проста: якщо T не числовий, студент побачить ваше повідомлення. Це все ще не concepts у повному сенсі, бо контракт не в сигнатурі, але вже крок у бік «людських» помилок.

5. Типові помилки під час роботи з concepts і constraints

Помилка № 1: вважати, що template <typename T> означає «будь-який тип» у звичному, побутовому сенсі.
Шаблон справді може прийняти на вході майже будь-який тип, але це не означає, що ваш код усередині буде коректним. Щойно в тілі зʼявляються +, *, size() або range-for, ви фактично вводите вимоги. Якщо ці вимоги не виражені явно, ви самі закладаєте міну на майбутнє: помилка спливе пізніше й виглядатиме страшніше, ніж могла б.

Помилка № 2: намагатися «лікувати» шаблонні помилки, переписуючи тіло, а не формулюючи контракт.
Новачки часто роблять так: побачили помилку про operator+ — і починають вигадувати костилі в тілі функції, аби все якось спрацювало. Проблема в тому, що тіло — не місце для вгадування типів. Спочатку корисно поставити собі питання: «А які типи взагалі має підтримувати ця функція?» І лише потім думати про реалізацію.

Помилка № 3: сприймати constraints як if-перевірки, які просто не дадуть програмі впасти.
Constraints — це не «захист від поганих значень», а «захист від неправильних типів». Якщо тип не підходить, програма не має збиратися. Це не жорстокість, а економія часу: ви не витрачаєте години на налагодження того, що взагалі не має сенсу виконувати.

Помилка № 4: «написати один шаблон на все» замість зрозумілого API.
Іноді хочеться зробити одну суперфункцію process(T x), а всередині — 200 рядків: «якщо тип має size() — робимо одне, якщо є operator+ — інше…». Такий код швидко перетворюється на кашу. Concepts цінні тим, що допомагають розділяти поведінку за контрактами типів і робити інтерфейс чеснішим та передбачуванішим.

Помилка № 5: думати, що concepts потрібні лише «у стандарті» й «у бібліотеках».
Щойно ви пишете хоча б одну шаблонну утиліту у своєму застосунку, а ми вже пишемо, ви фактично створюєте маленьку бібліотеку для самого себе. І саме там, у «своєму маленькому світі», зрозумілі помилки й явні контракти економлять найбільше часу — бо налагоджувати будете ви, а не комітет C++.