inline‑функції та inline‑змінні

1. Чому «просто покласти функцію в .hpp» не можна

Якщо ви щойно почали писати багатофайлові проєкти, дуже легко потрапити в пастку: «заголовок же підʼєднується через #include, отже там можна написати все: і оголошення, і визначення». У певному сенсі це так: текст заголовка справді підставляється в кожен .cpp, який його підʼєднав. Проте саме в цьому й криється проблема.

Уявімо, що в нас є заголовок task_utils.hpp, і ми написали в ньому звичайну (не inline) функцію з тілом. Потім цей заголовок підʼєднали до main.cpp і task_storage.cpp. У результаті компілятор чесно згенерує дві копії однієї й тієї самої функції в двох обʼєктних файлах, а компонувальник скаже: «Мені не подобається, що ви передали мені два однакові символи».

Ось невеликий приклад того, як зламати збирання (спрощено):

// task_utils.hpp
#pragma once

int clamp_priority(int p) {          // <-- визначення в заголовку (небезпечно)
    if (p < 1) return 1;
    if (p > 5) return 5;
    return p;
}

Якщо task_utils.hpp підʼєднати до двох .cpp, то ви майже напевно побачите помилку компонування типу multiple definition.

Щоб краще уявити, що відбувається, корисно подумки намалювати таку схему:

flowchart TD
    H["task_utils.hpp
(текст із тілом функції)"]
    A["main.cpp"] -->|#include| H
    B["task_storage.cpp"] -->|#include| H

    A --> OA["main.o
(містить clamp_priority)"]
    B --> OB["task_storage.o
(містить clamp_priority)"]

    OA --> L["компонувальник"]
    OB --> L
    L -->|помилка: multiple definition| X["збирання не вдалося"]

Тобто проблема не в тому, що «компілятор не зрозумів код». Навпаки — він усе зрозумів. Проблема в тому, що компонувальник побачив більш як одне визначення одного й того самого символу.

2. Що насправді робить inline і чого він не робить

Слово inline історично звучить так, ніби означає «вбудувати код функції просто в місце виклику». І компілятори справді вміють робити «вбудовування» (inlining) як оптимізацію. Але в сучасному C++ це вже давно не головна причина існування ключового слова inline.

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

Із цього випливають два наслідки, які варто запамʼятати як мантру й повторювати щоразу, коли виникає думка: «а давайте все зробимо inline».

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

Другий наслідок: inline дозволяє тримати визначення в заголовку, який підʼєднується до багатьох .cpp. Але вимога при цьому залишається суворою: визначення мають бути однаковими. Не «схожими», не «майже однаковими», а однаковими за змістом. Інакше ви вже порушуєте ODR, лише хитрішим способом. І такі порушення інколи проявляються «дивними багами», а не гарною помилкою компонувальника.

3. inline‑функції в .hpp: як писати і навіщо

Тепер перенесімо це на практику. Нам часто хочеться тримати маленьку утиліту поруч із оголошенням, щоб не бігати між .hpp і .cpp, особливо якщо функція дуже коротка й очевидна. Наприклад: «обмежити число діапазоном» або «перевірити, що пріоритет — від 1 до 5». Для таких випадків inline підходить якнайкраще.

Міні‑приклад: робимо маленьку утиліту коректно

Нехай ми пишемо простий консольний застосунок «TaskBook» — міні‑менеджер задач. У кожної задачі є заголовок і пріоритет 1..5. Ми хочемо мати функцію, яка приводить значення пріоритету до потрібного діапазону.

// task_utils.hpp
#pragma once

inline int clamp_priority(int p) {
    if (p < 1) return 1;
    if (p > 5) return 5;
    return p;
}

Ключовий момент: тепер цей заголовок можна підʼєднати хоч до 20 .cpp, і компонувальник не буде лаятися на multiple definition, бо inline змінює правила для ODR.

Коли inline‑функція — хороший вибір

На практиці inline‑функція в заголовку добре працює як маленька «цеглинка», що виконує одну просту дію і не тягне за собою половину проєкту. Важливо, щоб це була функція, яку зручно читати просто в заголовку: коротка, без сюрпризів і без прихованих залежностей.

Наприклад, така перевірка читається миттєво:

// task_utils.hpp
#pragma once

inline bool is_priority_valid(int p) {
    return p >= 1 && p <= 5;
}

І в main.cpp:

#include <iostream>
#include "task_utils.hpp"

int main() {
    std::cout << is_priority_valid(3) << "\n";   // 1
    std::cout << is_priority_valid(99) << "\n";  // 0
}

Правило: «однакове визначення всюди»

inline не означає «можна мати дві різні реалізації». Воно означає: «можна мати одне й те саме визначення, яке зʼявилося в різних .cpp через #include».

Тому такий трюк — погана ідея, навіть якщо здається, що «так зручніше під Windows і Linux»:

// task_utils.hpp
#pragma once

inline int platform_magic() {
#ifdef _WIN32
    return 1;
#else
    return 2;
#endif
}

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

4. inline‑змінні: константи й налаштування без multiple definition

З функціями ми розібралися. Але є ще одна типова проблема новачка: «хочу константу в заголовку, щоб її бачив увесь проєкт». І далі часто зʼявляється таке:

// config.hpp
#pragma once
int kMaxTitleLen = 60; // <-- ініціалізація в заголовку = визначення (майже завжди погано)

Якщо config.hpp підʼєднати до кількох .cpp, ви отримаєте multiple definition уже на змінній. І саме тут у сучасному C++ (починаючи з C++17) зʼявляється потрібний інструмент: inline‑змінні.

«Правильна константа в заголовку»

Для константи це виглядає так:

// config.hpp
#pragma once

inline constexpr int kMaxTitleLen = 60;

Чому тут одразу два слова — inline і constexpr? Тому що вони розвʼязують різні задачі. constexpr каже: «це константа, відома на етапі компіляції». А inline каже: «її визначення може зʼявлятися в кількох одиницях трансляції, і це нормально з погляду ODR».

Якщо ви використовуєте таку константу в проєкті, вона поводиться як «одна сутність на всю програму» (з поправкою на те, що зараз ми обговорюємо прикладну модель; формальності стандарту глибші). Головне — ви більше не отримуєте multiple definition.

Невелика таблиця: що можна тримати в заголовку, а що краще не варто

Щоб не перетворювати inline на релігію, корисно тримати в голові таку «карту рішень»:

Останній рядок особливо важливий: inline‑змінна може бути й не constexpr, тобто змінюваною. Технічно це можливо. Але з погляду дизайну майже завжди саме звідси починаються пригоди в стилі «чому лічильник став 42, хоча я його не чіпав».

5. Практичний приклад: додаємо inline у CLI‑застосунок задач

Тепер зберімо все в невеликий фрагмент нашого «TaskBook». Уявімо, що проєкт уже багатофайловий і в нас є принаймні main.cpp, task_model.hpp і task_format.hpp. Ми хочемо зробити єдиний формат друку задачі й винести кілька констант.

Константи проєкту в заголовку

// config.hpp
#pragma once

inline constexpr int kMinPriority = 1;
inline constexpr int kMaxPriority = 5;
inline constexpr int kMaxTitleLen = 60;

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

Маленька inline‑утиліта для правил

// task_rules.hpp
#pragma once
#include "config.hpp"

inline bool is_priority_valid(int p) {
    return p >= kMinPriority && p <= kMaxPriority;
}

Зверніть увагу на залежність: цей заголовок підʼєднує config.hpp. Це нормально, тому що ми справді використовуємо ці константи. Але саме тут починається тема прихованих залежностей: якщо task_rules.hpp почне тягнути важкі заголовки, збирання проєкту відчутно сповільниться.

inline‑форматування рядка для виведення

Нехай у нас модель задачі поки проста: id, title, priority.

// task_model.hpp
#pragma once
#include <string>

struct Task {
    int id{};
    std::string title{};
    int priority{};
};

Тепер — заголовок форматування:

// task_format.hpp
#pragma once
#include <string>
#include "task_model.hpp"

inline std::string format_task_line(const Task& t) {
    return "#" + std::to_string(t.id) + " [" + std::to_string(t.priority) + "] " + t.title;
}

І використання в main.cpp:

#include <iostream>
#include "task_format.hpp"

int main() {
    Task t{1, "Buy milk", 3};
    std::cout << format_task_line(t) << "\n"; // #1 [3] Buy milk
}

Так, функція форматування вже не на три рядки, але вона все ще досить невелика, щоб її було зручно тримати в заголовку і бачити формат виведення просто поруч із оголошенням. Якщо ж формат стане складним (вирівнювання, ширини, локалізація), тоді логічніше винести її в .cpp, щоб не роздувати заголовки.

6. Де inline починає шкодити: компіляція, залежності й «магія»

Після того як inline урятував нас від multiple definition, легко спокуситися думкою: «Ага, отже, тепер я можу все тримати в заголовках, і .cpp більше не потрібен». Ця спокуса зрозуміла, але зазвичай шкідлива.

По‑перше, визначення в заголовках означають, що після будь-якої зміни заголовка доводиться перескладати всі .cpp, які його підʼєднують. А якщо ви поклали в заголовок половину проєкту, то «змінив один рядок» швидко перетворюється на «піду заварю чай, поки воно компілюється».

По‑друге, inline‑функції в заголовках часто тягнуть за собою #include‑залежності. Сьогодні ви додали <vector>, завтра — <algorithm>, післязавтра — ще кілька заголовків. А потім дивуєтеся: «Чому збирання таке повільне? Я ж усього лише додав маленьку inline‑функцію».

По‑третє, inline дуже легко використати для створення спільного глобального стану у вигляді змінюваних inline‑змінних. Технічно це працює, але з погляду архітектури перетворює проєкт на кімнату з однією лампочкою й десятьма вимикачами на різних стінах: світло то вмикається, то ні, а хто винен — незрозуміло.

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

7. Типові помилки під час використання inline

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

Помилка №1: вважати, що inline = «прискорити код».
Якщо ставити inline «для швидкості», то ви, найімовірніше, розвʼязуєте не ту задачу. У сучасному C++ компілятор сам вирішує, чи вбудовувати функцію, і часто робить це краще, ніж людина навмання. А справжнє призначення inline у межах цієї теми — дозволити однакові визначення в кількох одиницях трансляції, тобто коректно пройти ODR.

Помилка №2: позначати inline усе підряд, зокрема великі функції.
Найімовірніше, ви отримаєте повільне збирання і заголовки, які тягнуть за собою купу залежностей. У результаті будь-яка правка в «зручному заголовку» перескладатиме половину проєкту. Це не «помилка компілятора», а архітектурна помилка на рівні звичок.

Помилка №3: робити змінювану inline‑змінну як глобальний стан «на весь проєкт».
Технічно inline int g_counter = 0; у заголовку може працювати, але так ви створюєте спільний глобальний обʼєкт, доступний звідусіль. Такі речі швидко перетворюють налагодження на квест: змінна змінюється «сама», бо насправді її змінюють із десятка місць. Для констант inline constexpr зазвичай безпечний, а от змінюваний стан краще проєктувати обережно.

Помилка №4: допускати різні тіла inline‑функції в різних .cpp через #ifdef.
Це виглядає спокусливо («під платформи зроблю по‑різному»), але ви ризикуєте отримати порушення ODR у прихованому вигляді. Іноді воно проявляється одразу, іноді — лише в релізному збиранні, іноді — лише в одного з ваших колег. Якщо вже справді потрібне платформне розгалуження, його краще проєктувати так, щоб визначення не «розʼїжджалися» між одиницями трансляції.

Помилка №5: думати, що #pragma once (або include guards) лікують multiple definition.
#pragma once захищає від повторного підʼєднання заголовка всередині одного .cpp. Але якщо заголовок підʼєднано до двох різних .cpp, то він усе одно буде «присутній» двічі в програмі, і без inline (або винесення визначення в один .cpp) ви все одно отримаєте проблему на етапі компонування.