Прапори компілятора: -std=c++23, -O0/ -O2, -g і попередження

1. Прапори — це частина контракту збирання

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

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

Про збирання зручно думати так:

flowchart LR
    A[Вихідні файли .cpp/.hpp] --> B[Компіляція: g++/clang++ + прапори]
    B --> C[Об’єктні файли .o/.obj]
    C --> D[Компонування]
    D --> E[Виконуваний файл]

Прапори впливають переважно на блок компіляції: що вважати помилкою або попередженням, які правила мови діють, що саме оптимізувати. Частково вони впливають і на те, що потрапить до результату, наприклад на символи для налагодження.

2. -std=c++23: фіксуємо «мову», якою ви розмовляєте з компілятором

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

Прапор -std=c++23 — це ваша письмова домовленість із компілятором: «ми граємо за правилами C++23». Навіть якщо ви поки не використовуєте найновіші можливості, така дисципліна важлива: вона робить збирання відтворюваним.

Типова команда:

g++ -std=c++23 main.cpp -o app
# або
clang++ -std=c++23 main.cpp -o app

Мінідіагностика через __cplusplus

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

#include <iostream>

int main() {
    std::cout << "__cplusplus = " << __cplusplus << '\n';
    // Наприклад: __cplusplus = 202302 (значення залежить від компілятора)
}

Якщо ви зібрали програму без -std=c++23, значення може відрізнятися. І так, компілятори іноді поводяться по-різному, але сама ідея перевірки від цього не втрачає користі: ви принаймні бачите, що режим справді змінився.

3. Попередження: -Wall -Wextra -Wpedantic — «компіляторе, бурчи голосніше»

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

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

• -Wall — вмикає багато популярних попереджень. Історично назва оманлива: це не «all warnings», але прапор однаково дуже корисний.
• -Wextra — додає ще порцію попереджень, часто про речі в дусі «ніби працює, але виглядає підозріло».
• -Wpedantic — вмикає попередження про нестандартні розширення й «слизькі» місця з погляду стандарту.

Команда має такий вигляд:

g++ -std=c++23 -Wall -Wextra -Wpedantic main.cpp -o app

Приклад 1: «змінна є, сенсу немає» (unused variable)

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

#include <iostream>

int main() {
    int debugValue = 42;           // попередження: змінна не використовується
    std::cout << "Hello!\n";       // Hello!
}

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

Приклад 2: signed/unsigned-порівняння (класика жанру)

Ця проблема вам уже знайома з тем про size_t: v.size() повертає беззнаковий тип, а int — знаковий. Якщо порівнювати їх напряму, компілятор може видати попередження. І він матиме рацію: у деяких граничних випадках логіка може повестися несподівано.

#include <vector>

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

    for (int i = 0; i < v.size(); ++i) { // часто warning: signed/unsigned comparison
        (void)v[i];
    }
}

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

4. -Werror: перетворюємо «бурчання» на «стоп, так не можна»

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

Команда:

g++ -std=c++23 -Wall -Wextra -Wpedantic -Werror main.cpp -o app

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

Є і корисний компроміс: на етапі навчання можна збирати без -Werror, але періодично вмикати його для перевірки чистоти, коли ви готові довести код до ладу. У реальних командах -Werror часто вмикають у CI, щоб кодова база не деградувала.

5. Оптимізація: -O0 і -O2 — «швидко» vs «зрозуміло, що відбувається»

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

Прапор оптимізації задається як -O...:

• -O0 — оптимізації вимкнено. Зазвичай це режим «мені важливіші передбачувана діагностика й зрозумілість».
• -O2 — типовий «сильний» рівень оптимізації, який часто використовують для звичайного швидкого збирання.

Мініприклад, де оптимізація справді має сенс

Ми не будемо вимірювати час — це окрема велика тема. Але візьмімо код, у якому виконується багато операцій.

#include <iostream>

long long sum_to(int n) {
    long long s = 0;
    for (int i = 1; i <= n; ++i) {
        s += i;
    }
    return s;
}

int main() {
    std::cout << sum_to(1'000'000) << '\n'; // 500000500000
}

Зібрати можна так:

g++ -std=c++23 -O0 main.cpp -o app_debug
g++ -std=c++23 -O2 main.cpp -o app_fast

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

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

6. -g: діагностична інформація, щоб помилки були «з адресою»

Улюблена ситуація програміста-початківця: «воно впало, але де — невідомо». Щоб це «де» стало відомим, компілятор може додати до результату додаткові дані: звʼязок між машинним кодом і рядками вихідника, імена функцій, змінних (частково) та іншу службову інформацію.

Прапор -g вмикає генерацію налагоджувальної, або діагностичної, інформації:

g++ -std=c++23 -g main.cpp -o app_dbg

Часто -g використовують разом із -O0, щоб налагодження було більш «чесним»:

g++ -std=c++23 -O0 -g main.cpp -o app_dbg

Технічна деталь, яку варто тримати в голові без фанатизму: -g здебільшого збільшує розмір артефактів і робить діагностику змістовнішою. Це не «прапор уповільнення програми» як такий. Зазвичай на швидкість значно сильніше впливає саме -O0 vs -O2.

І так, ми ще будемо користуватися цим прапором, коли дійдемо до інструментів налагодження. Сьогодні нам достатньо розуміти: -g допомагає зробити так, щоб помилка була не просто «Segmentation fault (core dumped)» (умовно), а бодай мала шанс перетворитися на щось на кшталт «упало в такій-то функції, на такому-то рядку».

Профілі збирання: один набір прапорів для всіх .cpp

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

Правило просте: ключові прапори (-std=..., warnings, -O..., -g) мають застосовуватися однаково до всіх одиниць трансляції.

Нижче — два «профілі», які зручно тримати напохваті.

-std=c++23 -O0 -g -Wall -Wextra -Wpedantic

-std=c++23 -O2 -Wall -Wextra -Wpedantic

У вигляді команд:

# Debug
g++ -std=c++23 -O0 -g -Wall -Wextra -Wpedantic main.cpp -o app_dbg

# Fast
g++ -std=c++23 -O2 -Wall -Wextra -Wpedantic main.cpp -o app_fast

7. Роздільна компіляція: ті самі прапори, але з -c

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

Файли проєкту

Нехай у нас будуть такі файли:

• include/task.hpp — оголошення функцій.
• src/task.cpp — визначення функцій.
• src/main.cpp — точка входу.

include/task.hpp:

#pragma once
#include <string>
#include <vector>

void print_tasks(const std::vector<std::string>& tasks);

src/task.cpp:

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

void print_tasks(const std::vector<std::string>& tasks) {
    for (const auto& t : tasks) {
        std::cout << "- " << t << '\n';
    }
}

src/main.cpp:

#include "task.hpp"
#include <vector>

int main() {
    std::vector<std::string> tasks{"Buy milk", "Learn C++ flags"};
    print_tasks(tasks);
}

Роздільна компіляція з єдиним набором прапорів

Тепер компілюємо кожен .cpp в обʼєктний файл з однаковими прапорами:

g++ -std=c++23 -O0 -g -Wall -Wextra -Wpedantic -Iinclude -c src/task.cpp -o task.o
g++ -std=c++23 -O0 -g -Wall -Wextra -Wpedantic -Iinclude -c src/main.cpp -o main.o

Далі — компонування:

g++ main.o task.o -o tasklist_dbg

Зверніть увагу на невелику, але важливу деталь: -std=..., -O0, -g, попередження, -Iinclude — усе це стосується компіляції .cpp у .o. А компонування в простому випадку — це вже «збери з того, що вийшло». Якщо ви забудете застосувати прапори до одного .cpp, у вас фактично буде два різні світи, і компілятор навіть не зобовʼязаний вас утішати.

8. Часті поєднання прапорів і що вони насправді означають

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

-std=c++23

-Wall

-Wextra

-Wpedantic

-Werror

-O0

-O2

-g

9. Типові помилки під час роботи з прапорами компілятора

Помилка № 1: не вказувати -std=... і сподіватися на «якось воно буде».
Таке часто закінчується тим, що проєкт збирається в однієї людини, а в іншої — ні, хоча вихідні файли однакові. Причина нудна: різні стандарти за замовчуванням у різних версіях компілятора. Лікується ще нудніше, зате надійно: завжди явно писати -std=c++23.

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

Помилка № 3: використовувати -Werror як кийок на самому початку навчання.
-Werror робить збирання «суворішим за життя», і новачкові легко потонути у формальностях замість того, щоб зрозуміти суть. Вмикати його варто тоді, коли ви вже готові підтримувати проєкт у чистоті й хочете більше дисципліни. Спочатку розумніше звикнути до -Wall -Wextra, а -Werror підключати точково.

Помилка № 4: збирати частину .cpp з -O0 -g, а частину — з -O2, а потім дивуватися дивним ефектам.
Змішування режимів часто призводить до загадкових ситуацій: десь змінна «зникає», десь поведінку складніше діагностувати, а іноді навіть попередження відрізняються. Стабільніше мати один набір прапорів на весь проєкт і перемикати його цілком: «debug-профіль» або «fast-профіль».

Помилка № 5: думати, що -g — це «режим налагодження», а -O2 — «режим релізу», і більше нічого не потрібно.
Насправді це два незалежні виміри: -g відповідає за діагностичну інформацію, а -O... — за оптимізацію. Можна збирати і з -O2 -g — інколи так і роблять, — але важливо розуміти, навіщо саме ви це робите: оптимізація ускладнює «прозорість» того, що відбувається, навіть якщо символи є.