Опишите основные этапы сборки C/C++ проекта.

А, слушай, вот эта вся кухня с компиляцией — это же просто ёперный театр, если не понимать, что там внутри происходит. Ну представь, ты написал код, а потом он волшебным образом превращается в программу. Так вот, никакого волшебства, блядь, там нет, один суровый технарь-компилятор, который делает всё по шагам, как бухгалтер на зарплате.

Как всё разбирается по косточкам:

1. Препроцессинг (Preprocessing)

   • Что творится: Тут работает такой зануда-препроцессор, который ковыряется во всех этих директивах с решёткой #. Представь, он как тот чувак, который перед стройкой расчищает площадку.
   • Чем занят:
     • Вставляет файлы (#include): тупо берёт весь iostream и копипастит его тебе в код, вот прямо весь, до последней запятой. Овердохуища текста получается.
     • Раскрывает макросы (#define). Где было SIZE 1024, там теперь просто 1024.
     • Выполняет условные команды (#ifdef). Типа, «если дебаг, оставь этот код, а если релиз — выкинь нахуй».
     • Вычищает все комментарии. Всё, что ты так любовно писал после //, летит в мусорку. Жалко, да? А компилятору — да похуй.
   • Что получается: Огроменный промежуточный файл с расширением .i. В нём уже нет твоих красивых отступов и пояснений, один голый код.
   • Посмотреть можно так: g++ -E main.cpp -o main.ii. Сделай это разок и сам от себя офигеешь от объёма.

2. Компиляция (Compilation)

   • Что творится: А вот тут уже главный инженер, сам компилятор, берёт этот простыню-код и переводит его на язык железа — ассемблер. Это уже почти машинные команды, но ещё читаемые.
   • Что важно:
     • Он проверяет, не накосячил ли ты с синтаксисом. Не закрыл скобку — получи, дружок, ошибку компиляции.
     • Если попросишь флагами (-O2), он начинает оптимизировать код так, что порой сам чёрт ногу сломит. Выкидывает лишние операции, переставляет местами — в общем, колдует.
     • На выходе — ассемблерный листинг.
   • Что получается: Файл .s. Для непосвящённого — китайская грамота, но для процессора уже почти родная речь.
   • Команда: g++ -S main.ii -o main.s

3. Ассемблирование (Assembly)

   • Что творится: Работает ассемблер — тупой, но исполнительный переводчик. Берёт эти человеко-читаемые ассемблерные команды и превращает их в чистейший, беспримесный машинный код — нули и единицы, но упакованные в файл.
   • Что получается: Объектный файл (.o или .obj). Это уже почти готовая деталь, но в ней есть дырки. Например, ты вызвал функцию printf, а где её тело — хуй знает. Адреса не проставлены. В общем, деталь пока не в сборе.
   • Сделать можно так: g++ -c main.s -o main.o. Хотя честно, обычно первые три этапа делают одной командой: g++ -c main.cpp -o main.o.

4. Компоновка (Linking)

   • Что творится: А вот это самый, блядь, интересный и часто пиздецовый этап. Приходит линковщик. Его задача — взять кучу этих объектников (твои .o-файлы) и библиотек, и склеить их в одну работающую программу, как конструктор «Лего».
   • Он ищет: Ты в коде написал cout << "Hello", а где, сука, живёт сам cout? Линковщик идёт искать его в стандартной библиотеке или в тех .a/.so, которые ты указал.
   • Как склеивает:
     • Статически: Берёт код из библиотеки (файл .a) и тупо вставляет его копию прямо в твой исполняемый файл. Программа становится здоровенной, как бульдозер, зато самодостаточной. Ни от кого не зависит.
     • Динамически: Оставляет в программе лишь записочку: «функция printf, ищи её в файле libc.so.6». Сама библиотека подгружается уже при запуске. Программа — стройная, но если библиотеку удалить — всё, накрылась программа медным тазом, будет тебе хиросима с нагасаки.
   • Что получается: Наконец-то, готовый исполняемый файл! a.out, program.exe — то, ради чего всё затевалось.
   • Команда: g++ main.o utils.o -o myapp -lmylib

Короче, как это выглядит на практике и что полезно знать:

# Быстро и просто, чтобы не париться (всё делает компилятор сам, скрывая этапы)
g++ main.cpp utils.cpp -o program -O2 -std=c++17

# По-взрослому, раздельная компиляция (так делают в больших проектах, чтобы не пересобирать всё из-за одной строчки)
g++ -c main.cpp -o main.o -I./include   # -I говорит, где искать твои #include-файлы
g++ -c utils.cpp -o utils.o -I./include
g++ main.o utils.o -o program -L./lib -lmylib # -L и -l для указания, где и какую библиотеку линковать

# Посмотреть, какие макросы определены (иногда отладка, а иногда — удивление пиздец)
g++ -dM -E main.cpp
# Увидеть, от каких динамических библиотек твой шедевр зависит (чтобы знать, что тащить на другой комп)
ldd program      # Linux
otool -L program # macOS

Зачем это всё в голове держать? Да затем, чувак, что когда в сотне файлов вылезет ошибка undefined reference, ты не будешь, как мартышлюшка, тыкать в код пальцем, а сразу поймёшь — это промах линковщика, библиотеку не подключил. Или когда сборка длится полчаса, сообразишь, что можно пересобирать только изменённые .cpp-файлы. В общем, понимание этой кухни — это не хвастовство, а реальный инструмент, чтобы не тратить время, которого и так в обрез.