Си (C) для студентов: шпаргалка к экзамену и контрольным (МИФИ, МГУ, МФТИ)

Язык Си (C) — это не просто ещё один язык программирования, а фундамент всей компьютерной науки. Простое определение для экзамена: Си — это компилируемый, статически типизированный, процедурный язык программирования общего назначения с низкоуровневым доступом к памяти через указатели, созданный Деннисом Ритчи в 1972 году в Bell Labs для переписывания ядра Unix. На нём написаны ядра операционных систем (Linux, Windows, macOS), компиляторы, интерпретаторы (CPython, оригинальная JVM) и любое «железное» ПО, где важен каждый байт и каждый такт процессора. Разбор каждого слова определения для экзамена:

• Компилируемый — исходный код целиком переводится компилятором (gcc, clang, msvc) в машинный код конкретной платформы до запуска; получается отдельный исполняемый файл (.exe / ELF), который процессор выполняет напрямую. В отличие от интерпретируемых языков (Python, Ruby), где каждая строка читается и выполняется программой-интерпретатором на лету. Почему это важно: компиляция даёт скорость (нет посредника между кодом и процессором), но лишает переносимости «из коробки» — программу нужно перекомпилировать под каждую архитектуру (x86, ARM, RISC-V).
• Статически типизированный — тип каждой переменной известен компилятору до выполнения программы и проверяется на этапе компиляции. int x; — это всегда 4 байта целого числа, char *s; — это всегда указатель на символ, и компилятор не разрешит вам сложить указатель с другим указателем или передать int* в функцию, ожидающую char*, без явного приведения типа. Противоположность — динамическая типизация в Python, где тип «приклеивается» к значению в рантайме (x = 5; x = "hello" — законно).
• Процедурный — программа строится как последовательность вызовов функций (процедур), каждая из которых выполняет законченное действие и может вызывать другие. Нет классов, объектов, наследования в стиле ООП (хотя на Си можно имитировать ООП вручную через структуры и таблицы виртуальных методов). Почему это важно исторически: Си появился раньше объектно-ориентированной парадигмы (C++ создан в 1983 г. как «Си с классами»), поэтому весь его синтаксис построен вокруг функций и данных, а не вокруг «сообщений между объектами».
• Общего назначения — на Си пишут всё: от ядра ОС до веб-сервера, от драйвера принтера до нейросетевого фреймворка (тензорные вычисления TensorFlow внутри — это Си/C++).
• Низкоуровневый доступ к памяти через указатели — главная суперсила и главный источник ошибок. Указатель — это переменная, хранящая числовой адрес байта в оперативной памяти; через указатель программа может читать и писать любой байт, до которого «дотянется». В Python/Java таких возможностей нет в принципе.

Аналогия из жизни. Если Python или Java — это «автоматическая коробка передач» (удобно, безопасно, но вы не управляете мотором напрямую), то Си — это «механика»: вы сами выжимаете сцепление, сами переключаете передачу и сами видите, что происходит под капотом. Именно поэтому на Си пишут то, что должно работать максимально быстро и предсказуемо: ядро ОС, драйверы, микроконтроллеры, базы данных (PostgreSQL, SQLite), игровые движки и компиляторы к другим языкам. Расширенная аналогия для запоминания: в «автомате» (Python) компьютер сам решает, где хранить объекты, сам их удаляет, когда они не нужны, сам проверяет границы массива — вы просто «крутите руль и жмёте газ». В «механике» (Си) вы сами выбираете передачу (где разместить переменную — стек/куча/глобальная), сами следите за оборотами (следите за переполнением int, выходом за границы массива), и если заглохли (Segmentation Fault) — виноваты сами, потому что не выжали сцепление (не проверили указатель на NULL перед разыменованием).

Именно поэтому Си остаётся обязательной дисциплиной первых курсов технических вузов — на нём преподаватели проверяют не «знание синтаксиса», а понимание того, как программа реально работает в памяти компьютера: где физически лежат переменные (стек вызовов, куча malloc, сегмент данных, сегмент кода), как ходит указатель, почему printf иногда печатает мусор и куда девается выделенная память после free(). Четыре сегмента памяти — это базовая «карта местности», которую преподаватель ВМК МГУ и ФИВТ МФТИ ожидает увидеть на доске или на листке бумаги при любом вопросе про Си. Эта страница собрана под конкретную цель — экзамен, контрольную или коллоквиум по программированию в НИЯУ МИФИ, МГУ (ВМК) и МФТИ. Здесь нет истории языка и настройки IDE: только определения, тезисные ответы на теоретические вопросы, разобранные задачи без библиотечных функций, структуры данных с оценками сложности и вопросы с ответами. Формат — шпаргалка: плотные таблицы, короткий компилируемый код, типовые ловушки преподавателей. Отдельно разобрана теория алгоритмов (машина Тьюринга, нормальные алгоритмы Маркова, проблема останова), которую требуют на ВМК МГУ. Если нужен базовый синтаксис с нуля — начните с общей шпаргалки по Си, а эту страницу держите как экзаменационный конспект.

Почему именно «понимание памяти» — главное на экзамене. Любой современный высокоуровневый язык (Python, Java, C#) сам управляет памятью за программиста: сборщик мусора освобождает объекты, интерпретатор прячет указатели за «ссылками». В Си этого нет — вы сами решаете, где разместить переменную (на стеке, в куче, в глобальной области), сами выделяете память через malloc/calloc и сами освобождаете её через free. Это даёт скорость и контроль, но и ответственность: забытый free — утечка памяти, двойной free — крах программы, разыменование NULL — Segmentation Fault. Преподаватель на экзамене проверяет именно это умение «руками управлять памятью», потому что оно показывает, понимаете ли вы, как работает компьютер изнутри. Дополнительный аргумент для ответа преподавателю: понимание памяти в Си автоматически означает понимание, как работают Python и Java «под капотом» — потому что они сами реализованы на Си, и их сборщик мусора, и их «объекты», и их «массивы» — это всё те же байты по тем же адресам, просто спрятанные за синтаксическим сахаром.

Как пользоваться шпаргалкой. Экзаменационный ответ по Си держится на трёх китах: память (как данные лежат в байтах — стек вызовов, куча malloc, сегмент данных, сегмент кода), указатели (как к этой памяти обратиться по адресу и не выстрелить себе в ногу разыменованием NULL) и алгоритмы (как её обрабатывать эффективно, с оценкой сложности O(...)). Почему именно эти три темы, а не синтаксис или стандартная библиотека: синтаксис Си занимает 1 страницу (его можно выучить за вечер), стандартная библиотека — справочник (его можно открыть на экзамене, если разрешено), а вот «как код ложится на железо» — это то, что нельзя подсмотреть, и именно это отличает бакалавра от того, кто «прошёл курс по верхам». Именно об этом спрашивают из года в год, поэтому каждый раздел ниже построен по одному шаблону: сначала объяснение простыми словами (что это и зачем — через аналогии из жизни: указатель — это номер квартиры в почтовом ящике, массив — это шкаф с пронумерованными ячейками), затем готовые тезисы для устного ответа преподавателю, затем разобранный код с построчными комментариями «почему так», а в конце — типичные ошибки, за которые снижают баллы.

Три кита — простые определения для билета:

• Память — это оперативная память компьютера (RAM), представленная как массив байтов, каждый из которых имеет свой номер от 0 до N-1 (этот номер и есть адрес). Программа на Си при работе использует четыре логические области памяти: сегмент кода (машинные инструкции вашей функции, защищён от записи), сегмент данных (глобальные и static переменные, существуют всё время работы программы), стек вызовов (локальные переменные функций, аргументы, адреса возврата — растёт «вниз» от старших адресов, работает по принципу LIFO «последним вошёл — первым вышел», как стопка тарелок) и куча (heap) (динамически выделяемая память через malloc/calloc/realloc — растёт «вверх» от младших адресов, не управляется автоматически, программист обязан вызвать free). Подробнее о каждом сегменте (то, что спрашивают на МФТИ):
  • Сегмент кода (.text) — сюда загрузчик ОС копирует машинные инструкции из .exe/ELF-файла. Размер известен до запуска, защищён от записи (попытка *(char*)main = ... приведёт к Segmentation Fault). Сюда же попадают строковые литералы (в некоторых моделях — в отдельный сегмент .rodata).
  • Сегмент данных (.data / .bss) — .data хранит инициализированные глобальные/статические переменные (int g = 5; — попадёт сюда), .bss хранит неинициализированные (int g; — попадёт сюда, причём обнулённый). Особенность: эти переменные живут всю программу — от main() до exit(). Именно поэтому static int counter = 0; внутри функции сохраняет значение между вызовами.
  • Стек вызовов (call stack) — это «рабочий стол» текущей функции. При вызове функции в стек кладутся: аргументы (или указатели на них), адрес возврата (куда вернуться после ret), локальные переменные. При return всё это автоматически снимается со стека. Растёт «вниз» (от старших адресов к младшим) — это особенность архитектуры x86/ARM. Ловушка для экзамена: стек имеет фиксированный размер (по умолчанию ~1–8 МБ), и бесконечная рекурсия даёт stack overflow — переполнение стека.
  • Куча (heap) — это «склад» произвольного размера (ограничен только объёмом RAM + свопа). Вы запрашиваете блок у менеджера памяти через malloc(size), получаете указатель на него, работаете, потом обязательно вызываете free(ptr). Главное отличие от стека: куча не управляется автоматически, переменные в ней живут, пока вы их явно не освободите. Поэтому malloc используют, когда размер данных неизвестен на этапе компиляции (например, размер массива вводит пользователь).
  • Аналогия: стек — это стопка подносов в столовой (положил сверху — взял сверху, берёшь из середины — всё падает); куча — это склад, куда вы приходите и сами забираете коробку нужного размера, а потом обязаны вернуть её обратно.
• Указатель — это переменная, которая хранит не данные, а адрес другой переменной в памяти. Синтаксис: int *p = &x; означает «p указывает на x, *p — это значение по этому адресу, &x — взятие адреса x». Подробнее о трёх операциях с указателями (экзаменационный минимум):
  • &x — оператор взятия адреса (address-of), возвращает числовой адрес переменной x. Тип результата — «указатель на тип x» (т.е. int* для int, char* для char).
  • *p — оператор разыменования (dereference), идёт по адресу, хранящемуся в p, и возвращает значение, которое там лежит. Тип результата — тип того, на что p указывает (т.е. int для int*).
  • p + 1 — арифметика указателей: прибавление 1 сдвигает указатель не на 1 байт, а на sizeof(*p) байт (т.е. на 4 для int*, на 8 для double* на 64-бит). Именно поэтому a[i] эквивалентно *(a + i) — массив и указатель тесно связаны.
  • Аналогия: указатель — это номер квартиры на бумажке. Сама бумажка (переменная-указатель) хранит номер (адрес); идя по этому номеру, вы находите квартиру (область памяти), где живут жильцы (данные). Потеряли бумажку — NULL (нулевой адрес, означает «никуда не ведёт»); пытаетесь зайти в несуществующую квартиру — Segmentation Fault. Вторая аналогия для запоминания: указатель — это пульт от телевизора. Сам пульт — это переменная-указатель (хранит «адрес» телевизора, но сам телевизором не является). Кнопки на пульте (*p, p->field) — это операции, которые говорят «сделай что-то с тем, на что я нацелен». Батарейки сели (p == NULL) — кнопки нажимаются, но ничего не происходит, либо телевизор «взрывается» (Segfault).
• Алгоритмы и сложность O(...) — это способ оценить, как быстро работает ваш код при росте объёма данных. Запись O(n) означает «время работы растёт линейно с размером входа», O(n²) — «квадратично», O(log n) — «логарифмически». Шпаргалка по основным сложностям (та, что просят на МФТИ):
  • O(1) — константное время (доступ к элементу массива по индексу, вставка в хеш-таблицу в среднем).
  • O(log n) — логарифмическое (бинарный поиск, поиск в сбалансированном дереве).
  • O(n) — линейное (проход по массиву, поиск минимума/максимума).
  • O(n log n) — линейно-логарифмическое (быстрые сортировки: слиянием, кучей, qsort в среднем).
  • O(n²) — квадратичное (пузырьковая сортировка, сортировка выбором, вложенные циклы по массиву).
  • O(2ⁿ) — экспоненциальное (рекурсивное вычисление чисел Фибоначчи наивно, полный перебор всех подмножеств).
  • O(n!) — факториальное (перебор всех перестановок, задача коммивояжёра полным перебором).
  • Аналогия: найти слово в неотсортированном списке из 1000 элементов — O(n), придётся просмотреть в худшем случае все 1000; найти слово в отсортированном словаре методом половинного деления — O(log n), хватит ~10 шагов. Экзаменатор всегда спросит, почему ваш алгоритм именно такой, а не быстрее/медленнее. Готовый ответ на «почему O(n)?»: «потому что алгоритм выполняет ровно один простой проход по массиву, на каждом элементе делает O(1) операций, итого n · O(1) = O(n)».

Экзаменационный тезис (запомнить и уметь произнести вслух). Любая программа на Си одновременно существует в трёх измерениях: алгоритмическом (что она делает — логика, циклы, ветвления), модели памяти (где физически лежат данные — стек/куча/сегменты) и адресном (как к этим данным обращаются указатели, какие у них типы, что лежит по адресу). Если вы на экзамене можете объяснить только синтаксис кода, но не можете показать, где в памяти «живёт» каждая переменная и какой указатель на неё смотрит — ответ считается неполным, даже если код «правильно работает». Как произнести этот тезис за 30 секунд преподавателю: «Код на Си — это три слоя. Первый — алгоритм: что мы хотим получить. Второй — память: где физически лежат данные (стек, куча, сегмент данных). Третий — указатели: как из одной части кода обратиться к данным в другой части. Если я не могу объяснить все три слоя — я не понимаю код, я его просто списал».

Как готовиться по этой шпаргалке эффективно:

• Алгоритм «3 прохода». Первый раз прочитайте всё подряд как художественную книгу — поймите общую картину. Второй раз выпишите на карточки ключевые тезисы (одна карточка — один вопрос из экзаменационного билета). Третий раз — воспроизведите по памяти на бумаге без подглядывания. Почему именно три прохода работают (наука о памяти): первый даёт «общую карту местности» — формирует общее представление в долговременной памяти, второй — превращает пассивное чтение в активное выписывание (эффект активного припоминания, который ускоряет запоминание в 2–3 раза по сравнению с перечитыванием), третий — тест без подсказок, который покажет реальные «дыры» в знаниях и закрепит информацию через «эффект тестирования». Если на третьем проходе вы не смогли воспроизвести раздел — значит, его нужно читать заново, а не зубрить. Дополнительный совет: между вторым и третьим проходом сделайте перерыв минимум в один день — это нужно для «консолидации памяти», мозг во сне переносит информацию из кратковременной памяти в долговременную.
• Если времени мало — читайте только объяснения и тезисы, а код просматривайте глазами, мысленно проговаривая «что делает каждая строка и где это лежит в памяти». Что проговаривать про себя (мысленный поток): «объявляю int a — это 4 байта в стеке; int *p = &a — указатель тоже в стеке, хранит адрес a; *p = 5 — записал 5 по этому адресу, теперь и a, и *p равны 5». Такая «внутренняя речь» быстро формирует правильную ментальную модель. Усиленная техника для продвинутых: заведите блокнот и записывайте такие «мысленные потоки» для каждого примера из шпаргалки. Через 5–10 примеров вы заметите, что можете прогнозировать, что сделает код, ещё до его запуска — это и есть «интуиция программиста на Си».
• За день до экзамена обязательно воспроизведите 3–4 задачи по памяти на бумаге: нарисуйте стек вызовов, покажите стрелками указатели, посчитайте смещения в массивах структур через offsetof. На контрольной автодополнения и подсказок IDE не будет. Лайфхак для устного экзамена: когда преподаватель задаёт вопрос про указатели или массивы, возьмите лист бумаги и сразу нарисуйте прямоугольник «стек», прямоугольник «куча», прямоугольники-ячейки для переменных и стрелки для указателей. Преподаватели МИФИ/МФТИ это любят и оценивают дополнительно — вы показываете, что понимаете модель памяти, а не просто «знаете слова». Дополнительный лайфхак: рисуйте адреса внутри ячеек (например, 0x7fff5a00 для стека, 0x555a00 для кучи) — это сразу показывает преподавателю, что вы понимаете разницу между сегментами памяти.
• Типичная ловушка студента №1 — «выучить синтаксис, но не понять модель памяти». В результате на устном экзамене не можете ответить на простой вопрос «где физически лежит локальная переменная и когда она исчезнет». Не повторяйте эту ошибку — рисуйте память руками при каждом примере. Частный случай ловушки: студент знает, что malloc выделяет память, но не понимает, что после free указатель становится «висячим» (dangling pointer) и его обязательно нужно занулить (p = NULL;), иначе повторное free(p) — это UB и крах программы. Другой частный случай: студент путает «адрес переменной» и «значение переменной» — говорит *p = &x вместо p = &x или *p = x вместо p = &x. Лечится только одним способом — рисовать каждый пример на бумаге с разделением «указатель хранит адрес» vs «по адресу лежит значение».
• Типичная ловушка №2 — «пишу код, который компилируется, но содержит UB». Undefined Behavior (UB) — это ситуация, поведение программы в которой не определено стандартом Си: компилятор может сделать что угодно (от «работает» до «падает» до «выдаёт мусор»), и на разных платформах/компиляторах результат будет разным. Преподаватель в МИФИ/МФТИ за это снижает балл, даже если программа «работает у меня на компьютере». Поэтому в разобранных примерах ниже всегда отмечено, где начинается UB и почему. Топ-5 примеров UB, которые ловят на экзаменах (с пояснением, почему это UB): (1) выход за границы массива a[10] для массива размера 10 — потому что a[10] обращается к 11-му элементу, который не принадлежит массиву; компилятор не проверяет границы, и за этим адресом может лежать что угодно (чужой указатель, адрес возврата, мусор); (2) использование неинициализированной переменной int x; printf("%d", x); — потому что в этом месте стека может лежать остаток от предыдущего вызова функции, и значение x непредсказуемо; (3) двойной free(p) или free для указателя, не полученного из malloc — потому что менеджер памяти хранит список свободных блоков в специальной структуре, и двойное освобождение портит эту структуру, следующий malloc может вернуть мусор или упасть; (4) разыменование NULL-указателя *p при p == NULL — потому что адрес 0 (или 0xFFFFFFFFFFFFFFFF на некоторых платформах) зарезервирован ОС как «невалидный», обращение к нему вызывает Segmentation Fault; (5) переполнение знакового целого INT_MAX + 1 (для signed int это UB, для unsigned — определено по модулю 2³²) — потому что стандарт Си не определяет, как должно вести себя знаковое переполнение (компилятор может «оптимизировать» код, считая, что INT_MAX + 1 > INT_MAX, и удалить проверку if (x + 1 > x), что приведёт к удалению защитных условий в реальных программах). Дополнительно опасный UB: модификация строкового литерала char *s = "hello"; s[0] = 'H'; — UB, потому что строковые литералы лежат в защищённом от записи сегменте .rodata.
• Экзаменационный тезис №1 (золотой): любой код на Си — это всегда три вещи: что делает (алгоритм), где хранится (память) и как обращается (указатели). Если на экзамене не можете объяснить все три — ответ неполный. Практический совет: перед тем как писать код в билете, проговорите эти три пункта устно (или шепотом) — «алгоритм: ищу минимум в массиве; память: массив лежит в куче, индекс — локальная переменная на стеке; указатели: передаю в функцию указатель на первый элемент и длину». После этого код пишется почти сам. Расширение тезиса для пятёрки на МФТИ: добавьте четвёртый пункт — «сложность» (как быстро работает алгоритм). Тогда ваш ответ покрывает все четыре темы, которые проверяют на устном экзамене.
• Экзаменационный тезис №2 (про UB): компиляция без ошибок и предупреждений не означает корректность. В Си есть целый класс ошибок (UB), которые компилятор не ловит, но которые делают программу ненадёжной. Поэтому на экзамене, если код скомпилировался, это только полдела — нужно ещё раз проверить: нет ли выхода за границы массива, неинициализированных переменных, двойных free, разыменования NULL. Полезный приём: после написания кода пройдитесь по нему «взглядом компилятора» — представьте, что вы компилятор, и проверьте каждую строку на соответствие стандарту. Лайфхак: включите в gcc флаги -Wall -Wextra -Werror -fsanitize=address,undefined — эти флаги превращают многие UB из «молчаливых» в «падающие с диагностикой». Если ваш код компилируется с этими флагами — он почти наверняка корректен.
• Экзаменационный тезис №3 (про сложность): всегда указывайте сложность вашего алгоритма явно — O(n), O(log n), O(n²) — и умейте её обосновать через подсчёт операций. Если алгоритм рекурсивный — пишите рекуррентное соотношение (например, T(n) = 2·T(n/2) + O(n) для сортировки слиянием). Преподаватель спросит «почему O(n), а не O(n²)?» — ответ: «потому что каждый элемент обрабатывается ровно один раз в одном цикле, внешний цикл не открывает дополнительной работы на каждый элемент». Как обосновывать сложность по шагам: (1) посчитайте, сколько раз выполняется каждая строка; (2) выпишите суммарное число операций; (3) оставьте только старший член и уберите константы. Например, цикл for (i=0; i<n; i++) sum += a[i]; выполняет n итераций, в каждой — O(1) операций, итого n · O(1) = O(n). Если в коде два вложенных цикла for (i) for (j), то получается n · n = O(n²). Если цикл делит задачу пополам for (i=n; i>1; i/=2), то число итераций — log₂ n, итого O(log n).

Что проверляют на экзамене (по вузам)

Короткий словарь для навигации. Экзамен по программированию — это не только проверка знания синтаксиса, но и способность превратить условие задачи в работающий код, найти ошибку и обосновать выбор решения. Зачёт vs экзамен: зачёт мягче (допускается оценка «удовлетворительно»), экзамен строже (дифференцированная шкала). Коллоквиум — устная защита теории перед допуском к экзамену. Курсовая работа — законченная программа с отчётом и модульной сборкой. Процедурный C — это императивный стиль программирования, при котором код строится из функций, работающих с данными через аргументы и глобальные переменные; в нём нет классов, наследования и шаблонов — только структуры, массивы, указатели и обычные функции. Стандартная библиотека libc — набор готовых функций (strlen, strcpy, printf, malloc и др.), которые компилятор подключает по умолчанию; на контрольных МИФИ их использование часто запрещено. Инвариант цикла — логическое утверждение о состоянии переменных, которое остаётся истинным до входа в тело цикла, сохраняется после каждой итерации и из которого (вместе с условием выхода) следует правильный ответ программы. Алгоритмическая сложность — функция от размера входа, описывающая, как быстро растёт число операций или памяти; обозначается O (верхняя оценка), Ω (нижняя) и Θ (точная). Машина Тьюринга (МТ) — абстрактная вычислительная модель: бесконечная лента, головка, читающая и пишущая символы, и конечный автомат состояний; с её помощью формализуют само понятие «алгоритм». Нормальный алгоритм Маркова (НАМ) — другая формальная модель: программа задаётся упорядоченной системой подстановок строк, и алгоритм заключается в применении этих правил до тех пор, пока возможно. Проблема останова — классическая алгоритмически неразрешимая задача: нельзя написать программу, которая по тексту любой другой программы и её входу заранее определит, завершится та или «зависнет». Теорема Райса — обобщение: любое нетривиальное свойство результата программы алгоритмически неразрешимо. Метод двух указателей (two pointers) — техника, при которой два индекса (или итератора) движутся по массиву или строке в разных направлениях или с разной скоростью (например, «черепаха и заяц» для поиска цикла в списке). Утечка памяти (memory leak) — ситуация, когда выделенная через malloc память не освобождается через free, и процесс постепенно «съедает» оперативку. Переполнение (overflow) — выход значения за границы типа (int, signed char и т. п.) из-за арифметики; в C для знаковых типов это неопределённое поведение (UB), то есть компилятор не обязан реагировать предсказуемо.

Почему программы вузов различаются? Потому что разные специальности формируют разные компетенции: инженер-программист (МИФИ) — умеет писать «с нуля» без готовых библиотек; математик-программист (ВМК) — умеет доказывать корректность; прикладной разработчик (МФТИ) — умеет переходить с C на C++ и писать эффективный код. К этому стоит добавить ещё три практические причины. Историческая традиция кафедры: в МИФИ сильна школа системного программирования, опирающаяся на Кернигана и Ритчи и классический UNIX, поэтому много внимания уделяется низкоуровневым деталям. Профиль работодателя: ВМК готовит в Яндекс, ABBYY, академические институты — там ценят теорию, формальные модели и умение аргументировать; МФТИ — в IT-компании уровня Google, Yandex, Acronis, где важнее писать быстро и масштабируемо. Форма отчётности: вуз сам определяет, что удобнее проверять — письменную работу, устную защиту или автоматический тест, и программа подстраивается под формат.

Форма контроля и акценты различаются: где-то спрашивают чистый процедурный C без библиотек, где-то добавляют теорию алгоритмов, а где-то требуют C++ на базе C. Ниже — типичная картина по трём вузам; уточняйте программу своей кафедры.

Как читать эту таблицу на практике. Колонка «формат контроля» подсказывает, что именно тренировать. Там, где стоит «зачёт + экзамен», одинаково важны и устные определения, и письменные задачи. Где «письменный экзамен» — решают скорость и аккуратность рукописного кода: ошибку в одной строке преподаватель увидит и спросит, почему программа не скомпилируется. Где «1 задача + 2 вопроса» — умейте не только решить, но и объяснить своё решение вслух, потому что первым делом попросят прокомментировать алгоритм. Колонка «ключевые темы» — это фактический список билетов: если тема там названа, она почти наверняка всплывёт. Дополнительный лайфхак: посмотрите на строку своего вуза и на строку «соседа» — пересечение тем подскажет, что точно будет в билете, а уникальные пункты — где можно «набрать» дополнительные баллы глубиной. Если в вашей строке явно указаны «теория алгоритмов» или «STL», готовьтесь отвечать на определения устно, а не только писать код.

МИФИ. Курс строится вокруг «ручного» программирования: на контрольных запрещены strlen, strcpy и часто pow, поэтому нужно уметь писать их самому. Отдельно проверяют понимание представления чисел в памяти, переполнений и работы с файлами. Курсовая — законченная программа с модульной сборкой. Типичные задания: «вывести на экран все простые числа до N без библиотеки math», «подсчитать слова в тексте, не используя strtok», «считать матрицу из файла и транспонировать её». Ключевой навык — аккуратно работать с циклами и границами массивов, потому что санитайзеров на бумаге нет: ошибку вида i <= n преподаватель найдёт при чтении. Помните: если в задании сказано «без стандартных функций», это значит, что strlen, strcpy, pow, qsort и atoi писать нужно самостоятельно — за использование готовой вы получите ноль баллов за задачу. Практический совет: перед сдачей курсовой проверьте три вещи — компилируется ли проект «с нуля» командой make, покрыты ли .h-файлы include-охраной (#ifndef … #define … #endif), и работает ли программа с пустым входным файлом (частый «вопрос с подвохом» на защите). Дополнительно: на защите умейте рассказать, почему вы выбрали конкретную структуру данных и где именно в программе живёт каждая переменная (стек, куча, сегмент данных).

Аналогия из жизни. Контрольная МИФИ похожа на кухню, где вам дали только муку, молоко и нож: ни нарезанного хлеба, ни тёртого сыра. Всё нужно «приготовить» руками. Это не каприз преподавателя, а способ проверить, понимаете ли вы, как устроены strlen и strcpy «под капотом», а не просто умеете их вызывать. Точно так же повар-профессионал не пользуется полуфабрикатами: он знает, как замесить тесто, как поднять соус, как нарезать ровные кубики. Если вы «полуфабрикатный» повар, вы провалитесь там, где нет магазина за углом.

Почему именно так? Инженер, проектирующий встраиваемую систему или драйвер, обязан знать, что происходит на каждом такте процессора. Без понимания внутреннего устройства функций нельзя ни оптимизировать код под микроконтроллер, ни разобраться в причинах сбоя, когда готовых инструментов под рукой нет. Дополнительно: в системах реального времени (авионика, АСУ ТП, медицинские приборы) библиотеки часто запрещены по стандартам безопасности (MISRA C, DO-178C), потому что их поведение не всегда детерминировано и не покрыто формальной верификацией. Поэтому «ручное» программирование в МИФИ — это не архаизм, а репетиция индустриальных требований.

Типичные ошибки на контрольных МИФИ.

1. Забытый '\0' в конце самописной строки — функция «убегает» за границу массива, читает чужую память.
2. Замена pow(x, 2) на x*x без проверки диапазона: при больших x сразу ловим переполнение int. Безопаснее — (long long)x * x или явный каст к double.
3. Путают порядок fclose(fp) и проверки ferror(fp): закрыли файл — и ошибку записи уже не увидим, потому что буфер сбросится в fclose.
4. В задаче «посчитать слова» увеличивают счётчик после каждой буквы, а нужно — только при переходе из пробела в букву, иначе получают «слова» из одних пробелов и пустую строку в начале.
5. Забывают free() на одной из веток return — утечка памяти, которую на бумаге не запустишь, но преподаватель увидит по коду и снизит балл.
6. В реализации strcmp сравнивают через > вместо !=, из-за чего функция возвращает «неправильный» знак для лексикографического порядка.
7. При чтении из файла не проверяют возврат fscanf/fgets, и программа «падает» на пустом или битом файле — нужна явная проверка if (n != expected) { … }.
8. В рекурсивной функции забывают терминальное условие: на бумаге это выглядит «почти правильно», но при исполнении — переполнение стека; преподаватель снимает баллы за отсутствие if (n == 0) return ….
9. При работе с динамической памятью используют указатель после free() (use-after-free) или realloc без сохранения нового адреса — старый указатель становится «висячим».
10. В реализации atoi неправильно обрабатывают знак числа, пробелы по краям или пустую строку — программа «падает» или возвращает мусор; нужна явная обработка '-' и пропуск whitespace.

Экзаменационные тезисы МИФИ.

• Представление целых чисел в дополнительном коде и предсказание переполнения int ещё до запуска.
• Реализация strlen, strcpy, strcmp, atoi, pow «руками» — на автомате, без подглядывания в man.
• Чтение и запись текстовых и бинарных файлов через fopen / fread / fwrite / fclose и обработка EOF / ferror.
• Динамические массивы: malloc / calloc / realloc / free, связные списки на указателях.
• Курсовая: разбиение на .h / .c, Makefile, сборка из нескольких файлов и простая отладка gdb.
• Чтение кода с указателями: уметь по фрагменту сказать, где *p, где &x, чему равно *(&a[3]) и почему arr и &arr[0] — это одно и то же.
• Стек и куча: понимать, где живут локальные переменные, где — глобальные, а где — malloc-память; уметь изобразить стек вызовов для простой рекурсии.
• Побитовые операции: &, |, ^, ~, <<, >> — флаги, маски, выделение отдельных бит числа; типичная задача — установить/снять 3-й бит «регистра».
• Препроцессор: #define, #include, макросы с аргументами и подводные камни побочных эффектов (SQR(x++) — классический пример).
• Структуры и typedef: уметь описать структуру, обратиться к полю через . и через ->, выделить массив структур динамически.

МГУ (ВМК). Курс «Алгоритмы и алгоритмические языки» соединяет практику на C с теоретическим минимумом: формальные модели вычислений, оценки сложности, доказательства корректности. Коллоквиум — устная защита теории, письменный экзамен — задачи и определения. Отличительная черта: спрашивают не только «как», но и «почему это правильно» — например, просят доказать завершаемость алгоритма, оценить сложность по числу операций или сформулировать инвариант цикла. На коллоквиуме по машине Тьюринга будьте готовы построить МТ для конкретной задачи (например, «прибавить единицу к числу в унарном коде»), а по нормальным алгоритмам Маркова — применить правила подстановки вручную. Теоретический блок раздела ниже закрывает именно эти вопросы, поэтому его стоит учить наизусть, а не «понимать в общих чертах». Практический совет: доказательство корректности всегда стройте по схеме «инициализация → сохранение → завершение» — за каждый пропущенный пункт снимают баллы; оценку сложности записывайте не просто «O(n)», а с кратким обоснованием «внешний цикл n раз, внутренний не более n/2, итого O(n²)». На устном коллоквиуме сначала дайте определение термина и только потом — пример; преподаватели ВМК это ценят.

Аналогия из жизни. Если практика на C — это вождение автомобиля, то теория алгоритмов — это правила дорожного движения и физика работы двигателя. Можно ездить и без знания физики, но инженер-конструктор обязан понимать, почему машина тормозит и почему алгоритм завершается. Иначе любой «занос» на программе останется необъяснимым. Вспомните, как автогонщик высшего класса чувствует машину: он не просто нажимает педали — он знает, что именно происходит в моторе в каждый момент. Точно так же на ВМК ждут от вас не «работает и ладно», а «я могу объяснить, почему это работает».

Почему именно так? Будущий учёный или системный архитектор должен уметь не просто написать программу, а убедить коллег в её правильности. Без формального доказательства работающий код — это лишь гипотеза, проверенная на нескольких входах, а не строгое решение задачи. В науке это разница между «экспериментально наблюдали» и «теорема доказана»: первое — повод проверить дальше, второе — повод использовать как опору для новых результатов.

Типичные ошибки на ВМК.

1. Путают «доказательство корректности» с «эмпирической проверкой на тестах»: 1000 пройденных тестов не доказывают правильность для всех входов.
2. Сложность алгоритма оценивают «на глаз», а нужно явно показать: «число операций пропорционально n², потому что внешний цикл выполняется n раз и вложенный тоже n».
3. Инвариант цикла формулируют как «сейчас i-й элемент правильный», но забывают три обязательные части: (а) инициализация — инвариант верен до входа в цикл, (б) сохранение — если верен до итерации, верен и после, (в) завершение — из инварианта при выходе из цикла следует требуемый ответ.
4. Путают машину Тьюринга с нормальным алгоритмом Маркова: МТ работает с лентой, головкой и состояниями, а НАМ — только с подстановкой строк по системе правил.
5. В доказательстве завершаемости не указывают убывающую функцию (например, «длина оставшегося отрезка» или «значение счётчика итераций»), без которой завершаемость строго не обоснована.
6. При построении МТ забывают, что у каждого состояния должны быть определены все переходы для всех символов на ленте — иначе это «дырявая» программа, которая не является корректной МТ.
7. В оценке сложности рекурсивного алгоритма пытаются «на глаз» прикинуть O, забывая про уравнение рекуррентности (T(n) = 2T(n/2) + n и т. п.) и мастер-теорему.
8. На коллоквиуме путают «разрешимое» и «полуразрешимое» (перечислимое): множество программ, которые останавливаются, перечислимо, но не разрешимо — это важное различие.
9. При анализе НАМ путают порядок применения правил: применяется первое подходящее правило из списка, а не «любое подходящее»; это меняет результат.
10. В оценке сложности забывают про «худший случай» и приводят оценку «в среднем» без указания распределения входов — преподаватель ВМК это ловит сразу.

Экзаменационные тезисы ВМК.

• Формулировка и доказательство корректности алгоритма через инвариант цикла.
• Оценка сложности O / Ω / Θ для итеративных и рекурсивных алгоритмов.
• Машина Тьюринга: построить МТ для простой задачи (инкремент, копирование, проверка чётности).
• Нормальные алгоритмы Маркова: применить систему подстановок и дойти до результата вручную.
• Структуры данных: список, стек, очередь, дерево — реализация на C и сложность операций.
• Вопросы разрешимости: что можно и что нельзя вычислить (проблема останова, теорема Райса).
• Тезис Чёрча–Тьюринга: уметь сформулировать и показать, что разные формальные модели (машина Тьюринга, лямбда-исчисление, нормальные алгоритмы) эквивалентны по выразительной силе.
• Рекуррентные соотношения: вывод мастер-теоремы для типовых случаев T(n) = aT(n/b) + f(n).
• Классы сложности P, NP, NP-полнота на уровне определений и примеров: уметь отличить задачу из P (сортировка) от NP-полной (перебор подмножеств).
• Метод «разделяй и властвуй»: уметь записать рекуррентность для сортировки слиянием и быстрой сортировки и оценить её сложность.

МФТИ. Зачёт по схеме «одна задача плюс два теоретических вопроса»: задача обычно на массивы, строки, рекурсию или списки, а вопросы — по памяти, указателям и алгоритмам. Продвинутый поток почти всегда переходит на C++, поэтому крепкая база C здесь особенно важна. Практический совет: на зачёте сначала проговорите идею решения словами («иду по массиву двумя указателями, потому что...»), и только потом пишите код — преподаватель оценивает именно ход мысли, а не скорость набора. Классические задачи: «развернуть односвязный список без дополнительной памяти», «проверить, является ли строка палиндромом, за один проход», «найти k-й по величине элемент массива». Если задача кажется слишком простой, в ней почти всегда спрятана ловушка — переполнение int, пустой вход или строка без '\0'. Лайфхак: перед тем как писать код на доске, набросайте 2–3 примера входов и вручную прогоните алгоритм — это занимает минуту, но почти полностью ловит ошибки «на бумаге». Дополнительно: на устном вопросе сначала определите термин своими словами, потом приведите пример, потом — контрпример (если применимо). Преподаватели МФТИ любят полноту картины.

Аналогия из жизни. Зачёт МФТИ похож на экзамен по вождению, где инспектор сначала спрашивает теорию («зачем нужен этот рычаг?»), а потом предлагает проехать по маршруту. Сначала — понимание, потом — действие. Именно поэтому задачу начинают с устного комментария: так вы показываете, что понимаете модель, а не воспроизводите заученный шаблон. Хороший водитель видит дорогу заранее, а не реагирует в последний момент — точно так же сильный программист «видит» выполнение кода по строчкам, не запуская его.

Почему именно так? На физтехе готовят инженеров и исследователей, которые будут работать в условиях, когда «автоматика подсказывает» недоступна: код пишется на бумаге, запускать негде, отладчика нет. Отсюда требование проговаривать алгоритм вслух — это тренировка внутренней модели выполнения, без которой невозможно ни отлаживать, ни предсказывать поведение программы. На олимпиадах и в работе с «чёрным ящиком» (чужим legacy-кодом) навык «прочитать код глазами» важнее, чем скорость набора на клавиатуре.

Типичные ошибки на зачёте МФТИ.

1. В задаче «найти k-й элемент» забывают, что k может быть больше длины массива или равно 0 — нужна явная проверка 0 < k && k <= n, иначе выход за границы или мусор в ответе.
2. При развороте односвязного списка «теряют» хвост: после next = cur->next; cur->next = prev; забывают правильный порядок prev = cur; cur = next; — и следующая итерация уходит в никуда.
3. Палиндром строки проверяют через strcmp(s, reversed) — это не «один проход»; нужно либо развернуть копию в новом массиве, либо идти двумя указателями с концов к центру.
4. Рекурсия без базы индукции — бесконечная рекурсия и переполнение стека. На бумаге не запустишь, но преподаватель увидит по отсутствию if (n == 0) return … и снимет баллы.
5. В теоретическом вопросе про указатели путают *p (разыменование) и &x (взятие адреса), а также забывают разницу между массивом и указателем — это «классика» зачётов МФТИ.
6. В задаче на рекурсию сначала пишут тело, а потом «забывают» про базу — получают «почти правильный» код, который уходит в бесконечность; тренируйтесь выписывать базу и шаг индукции отдельно.
7. При ответе на теоретический вопрос про const-корректность путают «указатель на константу» (const int *p) и «константный указатель» (int * const p) — это две разные вещи, и преподаватель МФТИ это регулярно проверяет.
8. В задаче «черепаха и заяц» забывают, что перед запуском цикла slow и fast должны указывать на head, а не на head->next — иначе цикл длиной 1 не обнаружится.

Экзаменационные тезисы МФТИ.

• Указатели и адресная арифметика: *, &, ->, разница между массивом и указателем, связь имени массива с адресом первого элемента.
• Связные списки: вставка, удаление, разворот на месте — без дополнительной памяти.
• Рекурсия: база индукции, шаг, оценка глубины стека и преобразование рекурсии в цикл.
• Метод двух указателей (two pointers): «черепаха и заяц» (поиск цикла), слияние отсортированных массивов.
• Готовность перейти на C++: классы, шаблоны, auto, ссылки и контейнеры STL — на фундаменте чистого C.
• Семантика const: различать const T *, T const *, T * const и const T * const — это регулярно встречается и в C, и в C++.
• Динамическая память в C++: понимать, зачем нужны new/delete, и в чём разница с malloc/free (вызов конструкторов и деструкторов, исключения при нехватке памяти).
• Введение в STL: vector, list, map, set, итераторы и алгоритмы — уметь выбрать контейнер под задачу и обосновать выбор.
• Ссылки vs указатели: в чём разница, когда компилятор «под капотом» превращает ссылку в указатель, и почему ссылка не может быть nullptr.
• RAII и умные указатели (unique_ptr, shared_ptr) на уровне идеи: ресурс привязан к времени жизни объекта, чтобы исключить утечки.

Теоретический минимум: определения и тезисные ответы

Здесь собраны темы, которые спрашивают устно и письменно. Каждая — короткие тезисы плюс минимальный пример кода, который можно воспроизвести на доске или в бланке. Отвечая на билет, держитесь схемы «определение → зачем нужно → как устроено → пример»: экзаменатор почти всегда снижает оценку за ответ без определения, даже если вы умеете писать код. Если формулировка вспоминается с трудом, сначала назовите определение, а потом раскрывайте детали — так вы получите хотя бы базовый балл. Полезно также держать в голове структуру «что → зачем → почему именно так → как проверить» — она совпадает с логикой экзаменационных вопросов и помогает не пропустить важную часть ответа. Практический совет: перед ответом мысленно произнесите «по определению это…», «это нужно для того, чтобы…», «работает это так: …», «проверить можно так: …» — четыре «якоря», за которые цепляется внимание преподавателя. Не пытайтесь сразу рассказать всё — лучше три пункта с примерами, чем десять тезисов без иллюстраций.

Что такое неопределённое поведение (UB)

Прежде чем разбирать конкретные темы, зафиксируем главное понятие, на которое ссылается половина ответов, — неопределённое поведение (UB, undefined behavior). Простое определение для билета: UB — это ситуация, в которой стандарт языка Си не предъявляет к программе никаких требований относительно результата выполнения. То есть компилятор формально имеет право сделать с такой программой что угодно: выдать любое число, «зависнуть», вылететь с ошибкой, удалить файл или «оптимизировать» опасный код в нечто совершенно непредсказуемое. Аналогия из жизни: UB — это как перейти дорогу на красный свет в незнакомом городе: обычно «проносит», но однажды не пронесёт, и предсказать этот момент невозможно. В Си UB принципиально отличается от ошибок в других языках: он не обязан вызывать аварийное завершение (segmentation fault) — он может «повезти» на вашей машине, у вашего компилятора и с вашими флагами оптимизации, и «не повезти» на экзаменационной машине у преподавателя. Поэтому главная опасность UB — его воспроизводимость: баг может годами не проявляться, а потом появиться после смены версии gcc, перехода на другой процессор или включения оптимизации -O2. Аналогия точнее: UB — это не спрятанная мина, а исписанная страница контракта, на которой компилятор имеет право нарисовать что угодно; пока страница пуста, всё работает, но в любой момент «правила» могут измениться. Именно поэтому экзаменаторы так любят вопросы про UB: проверяется понимание того, что в Си программист сам отвечает за корректность, а компилятор — лишь за перевод корректной программы в машинный код.

Почему стандарт допускает UB? Исторически это было сделано для двух целей: (1) дать компилятору свободу для агрессивных оптимизаций (например, компилятор вправе считать, что знаковое переполнение невозможно, и убрать проверки) и (2) учесть архитектурные различия (на разных процессорах переполнение ведёт себя по-разному). Отсюда практический вывод: UB — это контракт между программистом и компилятором, нарушение которого снимает с компилятора все обязательства. Развёрнутое объяснение «почему так»: стандарт Си создан в 1970-х годах, когда каждый такт процессора был на счету, а компиляторы были далеки от совершенства. Если бы стандарт требовал определённого поведения во всех «неоднозначных» ситуациях, разработчикам компиляторов пришлось бы добавлять десятки проверок в каждую инструкцию — и программы стали бы работать в разы медленнее. Проще сказать программисту: «не делай так», чем заставлять железо обрабатывать все возможные случаи. Это так называемая модель «доверенного программиста» (trusted programmer) — в отличие от Java или Python, где безопасность встроена в язык «по умолчанию».

Типичные источники UB, которые нужно назвать на экзамене (запомните как «большую пятёрку»):

• Переполнение знаковых целых (например, int x = INT_MAX; x++;). Беззнаковые целые при этом определены: они заворачиваются по модулю 2^N, то есть ведут себя как часы: после 255 идёт 0. Это частая «ловушка» в билетах: студенты путают знаковое и беззнаковое переполнение. Почему разница такая принципиальная: для беззнаковых типов архитектура x86 (и большинство современных процессоров) физически реализует «оборачивание» — флаг переноса просто отбрасывается, и поведение однозначно. Для знаковых — процессоры ведут себя по-разному (x86 генерирует исключение только при делении, ARM — то же), поэтому стандарт решил не навязывать конкретный вариант, а снять с себя ответственность.
• Разыменование NULL (обращение по нулевому указателю), «дикого» (неинициализированного) или висячего (указывающего на освобождённую память) указателя. Практический совет: при работе с указателями полезно сразу после free(p) писать p = NULL; — это «обнулит» висячий указатель, и попытка разыменования даст предсказуемый segfault, а не порчу произвольной памяти. Такой приём называется «защитным обнулением».
• Выход за границы массива и чтение неинициализированной памяти — компилятор не обязан проверять индексы «из коробки». Почему это разрешено: проверка каждого обращения к массиву добавляет несколько ассемблерных инструкций к каждой строке кода — для научных и системных программ это недопустимо. В Си действует принцип «доверяй программисту» (trust the programmer): если вам нужна проверка — пишите её сами (assert(i < n)).
• Множественные изменения одной переменной без sequence point (классический пример i = i++ + ++i; или a[i++] = i++;) — до C++11 и до принятия нового стандарта C11 в этом случае порядок вычислений не определён. Термин для запоминания: sequence point (точка следования) — это момент в программе, после которого все побочные эффекты предыдущих вычислений уже выполнены, а до следующего ещё не начались. В C11 точки следования остались, но к ним добавились более строгие правила «sequenced before / sequenced after», которые проще запомнить как «не изменяйте одну переменную дважды в одном выражении».
• Обращение к строковому литералу на запись (например, char *p = "hello"; p[0] = 'H';) — литералы в большинстве реализаций лежат в read-only памяти, и попытка записи приводит к аварийному завершению или порче данных. Развёрнутое объяснение: строковые литералы компилятор размещает в сегменте .rodata, который при загрузке процесса отображается в память с правами «только чтение». Любая попытка записи ловится аппаратной защитой страниц (page fault) и превращается в SIGSEGV. Но стандарт говорит именно про UB, потому что теоретически реализация может размещать литералы в обычной памяти — и тогда программа «молча» испортит литерал, а при следующем вызове функции вернёт испорченную строку. Поэтому безопасный стиль — всегда объявлять строковые литералы как const char *p = "hello";.

Дополнительно (для полного балла) полезно упомянуть: деление на ноль для целых, выход за пределы объекта через арифметику указателей, нарушение правил restrict, неправильное использование функций с переменным числом аргументов (неверный формат в printf), чтение значения объекта через указатель другого типа (aliasing rules), а в C11 — обращение к памяти через указатель на неактивный член объединения (для Си это формально UB, в отличие от C++). Аналогия для объединений (union): представьте, что union — это коробка с одним отделением, в которое можно положить либо молоток, либо отвёртку. Если вы уберёте молоток и попробуете «использовать» его как отвёртку — никто не гарантирует, что отвёртка окажется в руках; вы можете порезаться, уронить инструмент или случайно забить гвоздь шурупом. Так и с union: пока вы пишете в один член и читаете из того же — всё корректно; иначе — UB.

Правило-мнемоника: UB = «Uвеличить шанс, что препод найдёт баг». На экзамене полезно добавить, что флаги -fsanitize=address,undefined (AddressSanitizer и UndefinedBehaviorSanitizer) превращают скрытые UB в явные сообщения во время выполнения — это современная практика отладки, которая ловит большинство типов UB ещё на этапе тестирования. Практический совет: компилируйте свои программы командой gcc -Wall -Wextra -fsanitize=address,undefined -g program.c -o program — так называемые санитайзеры встроят в бинарник инструментацию, которая сообщит о каждом UB с указанием файла и строки. Это в десятки раз эффективнее, чем искать баги «руками» через отладчик. Типичная ошибка студентов — путать UB и unspecified behavior (неуказанное поведение): unspecified — это когда стандарт разрешает несколько вариантов, но каждый из них корректен, а UB — когда стандарт вообще ничего не гарантирует. Пример для запоминания: порядок вычисления аргументов функции в Си — unspecified (f(a, b) может вычислить a раньше b или наоборот), но оба варианта корректны. А вот разыменование NULL — UB, потому что вариантов «правильного» поведения нет вовсе. Третий термин для полноты: implementation-defined behavior (поведение, определяемое реализацией) — это когда стандарт разрешает выбрать один вариант, но требует от компилятора задокументировать выбор (например, размер int в байтах). Три термина часто путают на экзамене — держите их в голове как «не указано» / «определено реализацией» / «не определено вообще».

Алгоритм и его свойства

Простыми словами. Алгоритм — это рецепт: у него есть ингредиенты (входные данные), строгая последовательность действий (шаги) и готовое блюдо (результат). Рецепт борща нельзя выполнять «примерно» — порядок действий и их однозначность важны, иначе блюдо не получится (или получится, но совсем другое). Именно поэтому на экзамене первым делом спрашивают определение и свойства: это база для всего остального — от сортировок до машины Тьюринга. Без понимания этих свойств невозможно осознанно рассуждать о сложности, корректности и применимости программ. Аналогия глубже: алгоритм — это не сам рецепт, а идея рецепта, которая может быть записана на любом языке (русском, английском, в виде блок-схемы или кода на Си). Конкретная программа на Си — это лишь одна из записей алгоритма, причём такая, которую понимает компьютер.

Алгоритм — конечная последовательность однозначно понимаемых указаний исполнителю, приводящая от исходных данных к результату за конечное число шагов. Классические свойства (по А. Н. Колмогорову и школьной традиции, иногда называют «пятью свойствами алгоритма»):

• Дискретность — процесс состоит из отдельных, обособленных шагов; каждое действие выполняется строго после предыдущего (нет «размазанных» во времени операций). Аналогия: конвейер на заводе — изделие перемещается от станка к станку дискретно, не «плавно перетекает» от одного рабочего к другому. Каждый шаг имеет чёткое начало и конец.
• Детерминированность — при одних и тех же входных данных результат и последовательность шагов однозначны (никакой зависимости от случайностей, настроения процессора или фазы Луны). Аналогия: хорошо сделанный кулинарный рецепт — два повара, готовящие борщ по одному рецепту, должны получить одинаковый вкус (если, конечно, не добавлять ингредиенты «на глаз»).
• Массовость — алгоритм применим не к одной конкретной задаче, а к целому классу задач с общим правилом обработки (алгоритм сложения работает для любых двух чисел, а не только для 2 + 3). Аналогия: формула площади треугольника работает для любого треугольника — хоть с основанием 5, хоть с основанием 5 миллионов; частный случай «площадь треугольника со сторонами 3, 4, 5» — это не алгоритм, а задача.
• Результативность — алгоритм завершается за конечное число шагов и выдаёт результат (в том числе «нет решения» — это тоже валидный результат, важно понимать!). Частая ошибка: путать результативность с «успехом». Алгоритм поиска может вернуть «элемент не найден» — и это результат, а не провал. Алгоритм проверки пароля может вернуть «неверный пароль» — тоже результат.
• Конечность (сходимость) — запись самого алгоритма конечна, а число шагов ограничено (не путать с «завершимостью»; конечность относится и к описанию, и к процессу). Аналогия: рецепт на 10 страниц — это конечный текст, но варить борщ по нему 100 лет — нарушение результативности. Конечность относится к самому рецепту (его описание не бесконечно), а результативность — к процессу приготовления (он должен когда-то закончиться).

Мнемоника для запоминания свойств: «Дискретность, Детерминированность, Массовость, Результативность, Конечность» → короткая цепочка «Ди-Де-Ма-Ре-Ко». Расшифровка по вопросам экзаменатора: что делаем? — шаги (дискретность); одинаков ли ответ? — да (детерминированность); для многих ли задач? — да (массовость); получим ли ответ? — да (результативность); закончится ли? — да (конечность). Если преподаватель просит привести контрпример, скажите: «процесс, зависящий от случайных чисел (например, rand() % 2), не детерминирован — при одних и тех же входных данных он может дать разные ответы; бесконечный цикл без условия выхода (while (1) { ... }) нарушает результативность, потому что алгоритм никогда не выдаст ответ». Ещё один контрпример для массовости: программа, складывающая только числа 2 и 3, — она работает, но не является алгоритмом в строгом смысле, потому что решает лишь одну задачу. Дополнительный контрпример для дискретности: непрерывный физический процесс (например, движение стрелки часов от 0 к 12) — он плавный, без отдельных шагов, поэтому не является алгоритмом, хотя описывается математической формулой. Именно для того, чтобы такие процессы «оцифровать», и придумали понятие дискретности.

Иногда добавляют понятность (исполнитель умеет выполнять каждую команду из набора инструкций) и эффективность (разумные затраты времени и памяти, без «бессмысленного» перебора). Эти два свойства не входят в «каноническую пятёрку», но часто упоминаются в расширенных формулировках. Пояснение «зачем»: понятность важна, потому что алгоритм пишется для конкретного исполнителя. Рецепт «открыть банку шуруповёртом» невыполним для повара без шуруповёрта, но тривиален для мастера в гараже. Эффективность важна потому, что вычислительные ресурсы ограничены: алгоритм, который перебирает все перестановки массива из 1000 элементов, математически существует, но практически бесполезен (если только вы не готовы ждать 1000! лет). Формальная модель — машина Тьюринга: она задаёт точное понятие «вычислимая функция» и позволяет доказывать существование или невозможность алгоритма для конкретной задачи. Аналогия: машина Тьюринга — это абстрактный «самый простой компьютер»: бесконечная лента, головка, которая читает/пишет символы, и таблица правил. Любой алгоритм, который можно описать для реального компьютера, можно описать и для машины Тьюринга (это и есть тезис Чёрча-Тьюринга). Важно подчеркнуть на экзамене, что свойства — это требования к алгоритму как объекту, а не к конкретной программе: одна и та же задача может решаться алгоритмом с разной эффективностью (например, сортировка пузырьком и слиянием), и именно оценка эффективности приводит нас к понятию сложности и классам P/NP. Краткое пояснение про P и NP: класс P — задачи, которые можно решить за полиномиальное время (быстро); класс NP — задачи, решение которых можно проверить за полиномиальное время (быстро проверить, но не обязательно быстро найти). Вопрос «равны ли P и NP?» — одна из нерешённых проблем математики, за решение которой обещан миллион долларов. Типичная ошибка студентов — путать алгоритм и программу: программа — это запись алгоритма на конкретном языке, а алгоритм — абстрактная последовательность действий, которая может быть реализована на разных языках или даже выполнена человеком вручную. Типичный вопрос на экзамене: «Является ли программа алгоритмом?» Ответ: программа — это запись алгоритма. Сама по себе программа может содержать синтаксические ошибки и не быть алгоритмом вообще; если же она корректна и реализует алгоритм, то алгоритмом является лежащий в её основе метод, а не текст программы.

// Простейший линейный алгоритм: ни ветвлений, ни циклов,
// поэтому все пять свойств выполняются «по построению».
// Тип возврата double, а не float: точности float для вычислений мало.
double triangle_area(double a, double h) {
    double s = 0.5 * a * h;   // 1. подготовка данных: S = (1/2) * a * h
    return s;                 // 2. вычисление завершено, отдаём результат
}                             // 3. конец функции — алгоритм остановился за один шаг

Почему этот пример удобно приводить на экзамене: он линеен (дискретность видна как три отдельных действия: умножение, присваивание, возврат), детерминирован (для одних и тех же a и h результат один и тот же, никаких rand()), массивен (формула годится для любого треугольника с любыми стороной и высотой, а не для одного конкретного), результативен (всегда возвращает число типа double) и конечен (ровно один оператор вычисления, нет циклов и рекурсий). Сравните с рекурсивной функцией из раздела «Функции»: там результативность и конечность приходится доказывать отдельно — через наличие базы рекурсии и уменьшение аргумента на каждом шаге. Именно эта разница и есть типичный вопрос «объясните, почему рекурсия может нарушить свойство конечности»: если базового случая нет или аргумент не уменьшается, рекурсия уходит в бесконечность (переполнение стека) — и алгоритм перестаёт быть результативным. Как доказывать корректность рекурсивного алгоритма на экзамене: (1) укажите базовый случай, в котором функция возвращает ответ без рекурсивного вызова; (2) покажите, что на каждом шаге аргумент строго уменьшается (например, n-1 вместо n); (3) сделайте индуктивный вывод: если для n-1 функция работает, то и для n работает, а для базы — работает по определению. Ещё один частый экзаменационный вопрос: «Является ли алгоритмом программа, которая иногда зацикливается?» Ответ — нет, потому что нарушается результативность; алгоритм обязан завершаться и выдавать ответ (в том числе «ответ: зацикливаюсь» — но это уже мета-уровень). Уточнение для полного балла: программа, которая зацикливается при определённых входных данных, — это вообще не алгоритм; программа, которая зацикливается при любых входных — это просто ошибка, она не реализует никакого алгоритма.

Блок-схемы по ГОСТ

Простыми словами. Блок-схема — это рисунок алгоритма: каждое действие рисуют своей фигурой, а стрелки показывают порядок. Она нужна, чтобы объяснить решение без кода: на защите курсовой и на экзамене часто просят «нарисуйте схему», и оценивают не красоту, а правильные фигуры и подписанные ветви. Аналогия: блок-схема — это план эвакуации в здании, где стрелки ведут к выходу, а ромбы-развилки спрашивают «сюда или туда». Другая аналогия — рецепт блюда на кухне: каждая фигура — конкретное действие (нарезать, варить, подать), а стрелки — порядок шагов. Без схемы программист держит весь алгоритм в голове, и при росте кода до сотен строк это становится невозможным — поэтому блок-схема снижает когнитивную нагрузку и помогает заметить ошибки ещё до запуска программы. Развёрнутое объяснение «почему именно блок-схемы»: человеческий мозг лучше обрабатывает пространственную информацию, чем линейный текст. Схема из 15 блоков воспринимается за секунды, а программа из 50 строк читается минуту. Поэтому блок-схемы незаменимы при коллективной разработке: один разработчик рисует схему, остальные сразу понимают логику.

Схемы алгоритмов оформляют по ГОСТ 19.701-90 (ЕСПД) — он заменил ГОСТ 19.002-80 и ГОСТ 19.003-80. По содержанию это международный стандарт ISO 5807, но в русскоязычной учебной среде по привычке ссылаются на ГОСТ. Практическая подсказка: на экзамене достаточно назвать номер «ГОСТ 19.701-90» — это стандарт Единой системы программной документации (ЕСПД), разработанный ещё в СССР и по-прежнему действующий в РФ. Зарубежные аналоги называют этот же стандарт «flowcharts» и ссылаются на ISO 5807:1985 — содержание практически идентично. Основные символы:

Правила: поток идёт сверху вниз и слева направо, у ромба подписывают выходы («да»/«нет»), блоки соединяются только линиями потока, а не касанием. Почему именно так: «направление по умолчанию» убирает лишние стрелки и снижает визуальный шум; подписи выходов у ромба обязательны, потому что у одного условия могут быть ветки «да», «нет», «равно», «больше» — без подписи читатель не знает, какая ветка куда ведёт; запрет на касание блоков связан с тем, что в ГОСТ-е линия — это строгое указание на порядок выполнения, и две соприкасающиеся фигуры без стрелки — «серый поток», который стандарт запрещает. Дополнительное пояснение: касание блоков — это «неопределённый поток», в реальной программе аналог отсутствия явного goto: исполнитель (человек или компилятор) не знает, что делать дальше. Поэтому стандарт требует явных стрелок.

Дополнительные правила, которые любят на экзамене:

• Один блок «Начало» и один блок «Конец» на всю схему. Если в схеме несколько «выходов» (например, return из функции в середине), их показывают стрелками к терминатору «Конец», но сам терминатор рисуют один раз — на нём сходятся все ветки. Аналогия: в здании один вход и один центральный выход; даже если из каждого кабинета можно выйти на улицу, все дороги ведут к одному выходу. Это упрощает контроль: «алгоритм завершился» означает «достигнут терминатор Конец».
• Внутри блоков пишут осмысленные действия («x = x + 1»), а не код Си целиком: блок-схема отражает логику, а не синтаксис. Сравнение x > 0 записывают именно так, а не как вызов функции. Практическая подсказка: если в блоке не помещается текст, не пытайтесь уменьшить шрифт до нечитаемого — лучше разбейте действие на несколько блоков или используйте предопределённый процесс (вызов подпрограммы).
• Размеры фигур стандарт не фиксирует жёстко, но отношение сторон у прямоугольника должно быть близко к 2:1, а у ромба — примерно равным высоте и ширине. Зачем: стандартизированные пропорции помогают быстро «считывать» схему: прямоугольник «горизонтальный», ромб «квадратный» — глаз сразу узнаёт фигуру по силуэту.

Как запомнить символы (мнемоника): «овал открывает и закрывает, прямоугольник работает, ромб спрашивает, параллелограмм общается (ввод/вывод), двойной прямоугольник вызывает помощника». На экзамене чаще всего просят нарисовать схему для линейного алгоритма, ветвления (if) и цикла (while): цикл изображают ромбом с обратной стрелкой, возвращающейся к телу цикла. Для цикла for схема строится так: блок инициализации → ромб условия → тело → блок модификации → возврат к ромбу. Для do-while тело рисуется перед условием, а стрелка идёт от тела к ромбу и обратно к телу, что подчёркивает «сначала сделай, потом проверь». Типичный подвох на экзамене: в do-while проверка идёт после тела, поэтому в схеме стрелка от ромба «ложь» идёт на выход из цикла, а «истина» — обратно к телу. Это противоположно while, где «истина» ведёт в тело, а «ложь» — на выход. Запомните: «while сначала думает, потом делает; do-while сначала делает, потом думает».

Типичные ошибки в блок-схемах: забыли подписать выходы ромба «да»/«нет»; нарисовали два терминатора «Начало» (он должен быть один); соединили блоки касанием без стрелки; использовали прямоугольник вместо ромба для условия; поставили блок ввода/вывода в начало без терминатора; перепутали местами «да» и «нет» (где «да» — справа, а где — слева, в ГОСТ-е не указано, но принято, что «да» идёт вниз или вправо); использовали ромб с одним выходом (должно быть минимум два); нарисовали стрелку, идущую внутрь блока, а не от него. Дополнительные ошибки, которые тоже «снимают баллы»: стрелка входит в блок сбоку, а выходит сверху (входить можно с любой стороны, выходить — только снизу или сбоку, но не сверху, потому что это нарушает направление «сверху вниз»); в ромбе написано не условие, а действие (x = 5 вместо x > 0?); в блоке ввода/вывода написано printf(...) (это код, а в схеме пишут «Вывод: x»); не соединены все блоки (получается «висячий» блок, до которого нельзя добраться по стрелкам); отсутствует связь между концом одной ветки и блоком «Конец». На письменном экзамене за компактность снимают меньше баллов, чем за неверные фигуры, поэтому сначала проверьте, что каждая фигура соответствует таблице выше, и только потом улучшайте аккуратность. Алгоритм самопроверки перед сдачей: (1) найдите все ромбы и убедитесь, что у каждого подписаны оба выхода; (2) посчитайте терминаторы — должно быть ровно два («Начало» и «Конец»); (3) проверьте, что из каждого блока есть выход (стрелка) и вход (стрелка или начало потока); (4) пройдите по стрелкам от «Начала» и убедитесь, что достигаете «Конца» из любой ветки; (5) проверьте, что ни одна фигура не используется не по назначению (например, прямоугольник вместо ромба).

Структурные элементы, которые полезно знать:

• Соединитель (окружность) — используют, когда схема не помещается на одном листе или нужно избежать пересечения линий. Внутри пишут метку (букву или номер), одинаковую в обоих местах разрыва. Аналогия: это как ссылка «см. стр. 42» в книге — читатель знает, куда перейти, не листая всю книгу.
• Межстраничный соединитель — пятиугольник («домик») — по смыслу похож на обычный соединитель, но связывает блоки на разных листах. Практическая подсказка: на экзамене обычно хватает обычного соединителя; «домик» рисуют только для многостраничных схем, что бывает редко.
• Параллельные действия — жирная горизонтальная черта, из которой выходят несколько стрелок; в учебных схемах по Си встречается редко, но в стандарте описан. Где применяется: для отображения многопоточных алгоритмов, где несколько веток исполняются одновременно. В однопоточном Си это практически не используется.

Типы данных и представление в памяти

Простыми словами. Тип данных — это «формат ячейки»: он говорит, сколько байт занимает значение и как эти байты толковать. Одни и те же 4 байта могут быть целым числом int, вещественным float или четырьмя символами — смысл задаёт именно тип. Аналогия: типы — это разные коробки на складе: под гвозди — маленькая, под мебель — большая; положить данные «не в ту коробку» (например, прочитать float как int) — классический источник ошибок. Другая аналогия: тип — это система единиц измерения. Число 5 без типа — просто «пять чего?». Тип отвечает на вопрос: пять метров, пять килограмм или пять секунд. На экзамене этот вопрос проверяет понимание того, что размер типа в Си не гарантирован стандартом, а зависит от платформы и модели данных. Развёрнутое объяснение «почему размер не фиксирован»: стандарт Си намеренно оставляет точные размеры на усмотрение реализации, потому что в 1970-х годах разные процессоры имели разную «родную» разрядность. Сделать int строго 32-битным означало бы запретить компиляцию на 8-битных микроконтроллерах, где 32-битный int потребовал бы эмуляции. Стандарт задаёт лишь минимумы: short ≥ 16 бит, int ≥ 16 бит (но на практике 32), long ≥ 32 бит.

Базовые типы: char, знаковые и беззнаковые целые (short, int, long, long long), вещественные (float, double, long double), а также _Bool (bool из stdbool.h). Стандарт задаёт минимумы размеров, фактические определяет модель данных платформы: на 64-битном Linux это LP64 — long и указатель по 8 байт, int — 4. Расшифровка названий моделей данных: первая буква — размер long, вторая — размер указателя (pointer). LP64 = long 64-бит, pointer 64-бит (типичная 64-битная Unix-система: Linux, macOS). ILP32 = int/long/pointer 32-бит (32-битные системы и Windows). LLP64 = long long 64-бит, pointer 64-бит (64-битная Windows: int — 32, long — 32, long long — 64). Практическая подсказка: на экзамене, если не уверены в модели, скажите «на 64-битном Linux это LP64», и добавьте, что стандарт это не гарантирует — зависит от компилятора и платформы.

#include <stdio.h>
#include <limits.h>   // INT_MIN, INT_MAX, CHAR_BIT и другие границы целых

int main(void) {
    // sizeof возвращает size_t, поэтому печатаем через %zu, а не %d
    printf("char=%zu short=%zu int=%zu long=%zu long long=%zu\n",
           sizeof(char), sizeof(short), sizeof(int),
           sizeof(long), sizeof(long long));
    // %zu для размеров; void* печатаем как размер указателя (на Linux LP64 — 8)
    printf("float=%zu double=%zu void*=%zu\n",
           sizeof(float), sizeof(double), sizeof(void *));
    // Диапазон int берём из limits.h, а не «пишем руками»: так переносимо
    printf("INT_MIN=%d INT_MAX=%d\n", INT_MIN, INT_MAX);
    return 0;   // 0 — успешное завершение
}

Как хранятся целые. Знаковые целые хранятся в двоичном дополнительном коде: -x получается инверсией всех битов и прибавлением единицы (например, -1 в 32 битах — это 0xFFFFFFFF). Беззнаковые — обычные двоичные числа, где все биты «рабочие». Отсюда правило диапазона: знаковый n-битный тип вмещает от -2^(n-1) до 2^(n-1) - 1, а беззнаковый — от 0 до 2^n - 1. Для 32-битного int это примерно ±2.1·10⁹, для unsigned int — до 4.29·10⁹. Именно на этой границе чаще всего ловят переполнение: сумма двух больших int внезапно становится отрицательной. Аналогия для запоминания дополнительного кода: представьте одометр (счётчик пробега) автомобиля. Если он показывает 99999 и вы проехали ещё километр, стрелка «перескочит» на 00000. Дополнительный код — это математический трюк, который превращает вычитание в сложение: «вычесть 1» = «прибавить -1», а -1 в дополнительном коде выглядит как «все единицы». Процессор складывает и «автоматически» отбрасывает переполнение — получается правильный результат без отдельной схемы для вычитания.

Почему именно дополнительный код, а не прямой или обратный: дополнительный код позволяет процессору складывать и вычитать знаковые и беззнаковые числа одной и той же схемой — отдельная логика для «минуса» не нужна. Например, -1 + 1 в 32 битах: 0xFFFFFFFF + 1 = 0x10000000, после отбрасывания лишнего бита — 0x00000000, то есть ноль. Знаковое сложение работает «само собой». Если бы использовался знак-бит с прямой кодировкой, пришлось бы разбирать знаки отдельно, что дороже по транзисторам и медленнее. Историческая справка для полного балла: в ранних машинах (1950-е) использовали «знак-бит + модуль», где -1 и +1 отличались только старшим битом. Сложение требовало отдельной схемы: «если знаки одинаковые — складываем модули и ставим их знак; если разные — вычитаем модули и ставим знак большего». Дополнительный код избавил процессор от этой развилки: одно арифметическое устройство обслуживает и знаковые, и беззнаковые числа. Поэтому дополнительный код стал стандартом де-факто для всех современных процессоров — даже язык Си это учитывает (хотя формально стандарт разрешает и другие представления, но ни одна современная реализация ими не пользуется). Как хранятся вещественные. Определение для старта. Вещественное число (число с плавающей точкой, floating-point) — приближённое представление действительного числа, помещающееся в фиксированное количество битов (32 для float, 64 для double). Аналогия из жизни: это линейка с делениями — очень большие и очень маленькие числа на ней либо не помещаются, либо теряют точность. Другая бытовая аналогия: деньги в кошельке хранятся с точностью до копейки, поэтому «1/3 рубля» — это всегда округлённые 33 копейки, и при сложении трёх таких округлений никогда не получится ровно рубль. В Си используется стандарт IEEE 754: знак (1 бит), порядок (экспонента, 8 бит для float, 11 для double) и мантисса (23 / 52 бита). Почему именно IEEE 754: этот стандарт даёт одинаковые результаты на любом процессоре, который его поддерживает, и потому программа с вещественными числами ведёт себя предсказуемо при переносе между платформами. Почему именно такая разбивка битов: научная запись 1.xxx·10^k естественно ложится на двоичную систему, а раздельное хранение мантиссы и порядка позволяет охватить огромный диапазон значений при умеренной точности. Это даёт три важных следствия:

• Вещественные числа приближённые: 0.1 + 0.2 != 0.3 — последние биты теряются при округлении. На экзамене любят вопрос «почему нельзя сравнивать float через ==». Разбор типичной ошибки: даже проверка if (a == 1.0) ненадёжна — компилятор вправе соптимизировать выражение и свернуть его в 1, что иногда «помогает», а иногда ломает логику программы.
• Есть специальные значения: +Inf, -Inf, NaN (например, 0.0 / 0.0 даёт NaN). Любая операция с NaN тоже даёт NaN — это удобно для поиска ошибок в вещественных вычислениях: «отравив» результат в одном месте, NaN «протаскивается» дальше и сигнализирует о сбое в самом конце цепочки, что упрощает отладку «от конца к началу».
• Диапазон float — примерно ±3.4·10³⁸ с точностью около 7 десятичных цифр; double — ±1.8·10³⁰⁸ с точностью ~15 цифр. Почему именно такой диапазон: порядок со смещением (bias) позволяет эффективно сравнивать вещественные как целые, но само смещение «съедает» половину диапазона экспоненты. Для финансовых и точных расчётов double обычно недостаточен, и используют библиотеки десятичной арифметики (например, libdecnumber или встроенные decimal типы в других языках), потому что даже 15 цифр не спасают от округлений в бухгалтерии.

Фиксированные типы (<stdint.h>). Определение для старта. Фиксированные целочисленные типы — это типы с гарантированным размером в битах (например, ровно 32 бита), в отличие от базовых int и long, чей размер зависит от платформы. Аналогия из жизни: int — это «палка с разметкой, длина которой зависит от страны», а int32_t — это «линейка, на которой гарантированно 32 сантиметра, где бы вы её ни купили». Чтобы не зависеть от платформы, в стандарте C99 ввели типы с гарантированным размером: int8_t, int16_t, int32_t, int64_t и соответствующие беззнаковые uintN_t, а также «как минимум N бит» типы int_leastN_t (минимально возможный тип, в который влезает N бит — экономит память) и «быстрые» int_fastN_t (самый быстрый тип, в который влезает N бит — на x86 компилятор обычно выбирает int или long). Для вывода используют макросы из <inttypes.h>: PRId64, PRIu32 и т. д. — они подставляют правильный модификатор длины (l, ll, h и т. д.) в строку формата. Почему это важно: наивный код printf("%lld", x) сломается на Windows, где long long обычно 8 байт, а на старых системах long мог быть 4 байта; макросы PRIdN автоматически подстраиваются под платформу. Это идиоматический способ писать переносимый код для бинарных форматов и сетевых протоколов, где размер поля фиксирован по спецификации, а не по воле компилятора. Практическая подсказка: при работе с бинарными файлами и заголовками пакетов всегда берите uint8_t, uint16_t, uint32_t — это делает размер поля очевидным при чтении кода.

Модель данных. Определение для старта. Модель данных — это соглашение компилятора и ОС о том, сколько байт занимают базовые типы C (char, short, int, long, long long, указатель). Аналогия: это «система мер», в которой работает конкретный компилятор: одна и та же величина long в разных странах может означать разные числа байт. Запомните три модели: LP64 (Linux, macOS — long и указатель по 8 байт), ILP32 (32-битные системы — всё по 4), LLP64 (Windows — long 4 байта, но указатель 8). Почему именно так: на 64-бит Linux исторически решили, что long и указатель растут вместе (чтобы сравнения указателей и long оставались простыми и не требовали приведений), а на Windows сделали long 32-битным ради совместимости со старыми DLL и API, которые рассчитывали на 4-байтный long. Практический вывод: printf("%ld", 10000000000L) на Windows и Linux напечатает разное, потому что long разной ширины. Для переносимого кода берите типы из <stdint.h> (int64_t) и форматы из <inttypes.h> (PRId64). Типичная ошибка: писать long для «большого числа» и потом удивляться, что на Windows оно не влезает или %ld ведёт себя неожиданно — лучше сразу использовать int64_t и PRId64.

Размер указателя и его связь с типом. Определение для старта. Указатель — это переменная, хранящая адрес другой переменной в памяти; тип указателя (int *, char *, void *) говорит компилятору, как интерпретировать данные по этому адресу при разыменовании *p и арифметике. Аналогия из жизни: адрес в памяти — это номер квартиры в доме, а тип указателя — это подсказка «здесь живёт int» или «здесь лежит строка». sizeof(void *) равен размеру указателя, а он равен разрядности адресации. На 32-битной системе — 4 байта, на 64-битной — 8. Почему именно так: размер адреса определяется разрядностью шины данных и регистров процессора: 32-битный регистр может хранить только 2³² разных адресов, а значит, указатель обязан уместиться в регистр. Указатель на char (char *) и указатель на int (int *) занимают одинаково, потому что указатель хранит только адрес, а не тип — тип нужен только компилятору, чтобы правильно выполнять *p и арифметику указателей (в байтах шаг = sizeof(T)). Поэтому sizeof(int *) == sizeof(char *) == sizeof(void *). Исключение: указатели на функции могут быть другого размера (например, в режиме «far» в старых архитектурах или в режиме PIC/PIE с переходниками) — на практике это значит, что сравнивать указатели на функции и на данные нельзя, и в стандарте C это явно сказано.

Порядок байтов (endianness). Определение для старта. Порядок байтов (endianness) — это способ, которым многобайтовое число записывается в память: в каком порядке идут байты — от младшего к старшему или наоборот. Аналогия из жизни: представьте, что вы записываете число «двенадцать тысяч триста сорок пять» как «12345». Один человек запишет слева направо «1-2-3-4-5» (big-endian, «как читаем»), а другой — справа налево «5-4-3-2-1» (little-endian, «единицы сначала»). Многобайтовые числа хранят двумя способами: little-endian (младший байт по младшему адресу; x86, ARM) и big-endian (старший байт первый; сетевые протоколы, часть RISC). Почему это важно: одна и та же последовательность байтов на разных платформах интерпретируется как разные числа, поэтому при чтении бинарных файлов и сетевых пакетов нужно либо фиксировать порядок, либо преобразовывать его. Это важно при чтении бинарных файлов и сетевых пакетов: одна и та же последовательность байтов на разных платформах даёт разные числа. На экзамене любят вопрос «что покажет этот код на little-endian?» — самый надёжный способ проверить самостоятельно через union { int i; unsigned char b[4]; } (все члены union делят одну и ту же память, поэтому изменение через i видно через b).

Пример типового вопроса: «дан массив байт {0x78, 0x56, 0x34, 0x12} на машине с little-endian. Что в нём хранится в виде 32-битного int?». Ответ: 0x12345678, потому что младший байт (0x78) лежит по младшему адресу. На big-endian тот же массив прочитал бы как 0x78563412. Поэтому сетевые протоколы (TCP/IP) исторически используют big-endian и называют его «network byte order»: чтобы разные машины могли одинаково интерпретировать заголовки пакетов, отправитель переводит свой порядок в big-endian функциями htonl / htons, а получатель переводит обратно через ntohl / ntohs. Практическая подсказка: при записи собственного бинарного формата всегда фиксируйте endianness в спецификации и используйте htonl/ntohl или ручную пересборку байт через сдвиги — это страхует от переноса кода на другую архитектуру.

Целочисленная арифметика, знаковость и переполнение

Простыми словами. У целых чисел есть два «режима»: знаковый (можно отрицательные) и беззнаковый (только 0 и положительные, но вдвое больший максимум). Си автоматически переводит один режим в другой при сравнении и арифметике — и именно здесь прячутся самые коварные ошибки. Аналогия: беззнаковое число — это счётчик оборотов спидометра, который после максимума снова показывает ноль; знаковое — термометр, который умеет уходить в минус. Другая аналогия: знаковое число — это банковская карта с овердрафтом, которая может уйти в минус, а беззнаковое — копилка, которая может быть только полной или пустой; при попытке забрать больше она показывает ноль. Главное правило: переполнение знакового — это UB (что угодно), а переполнение беззнакового строго определено (заворот). Почему так: для беззнакового заворот — естественное продолжение модульной арифметики по модулю 2^N, и любая реализация его гарантирует. Для знакового стандарт оставляет поведение неопределённым, потому что исторически разные процессоры вели себя по-разному (x86 заворачивал, MIPS ловил исключение), и закреплять что-то одно мешало бы оптимизациям компилятора.

При смешении знакового и беззнакового операндов знаковый приводится к беззнаковому: -1 превращается в UINT_MAX, и сравнение -1 < 1u даёт ложь.

#include <stdio.h>
#include <limits.h>

int main(void) {
    unsigned u = 1;
    // -1 имеет тип int, но при сравнении с unsigned превращается в UINT_MAX,
    // а UINT_MAX < 1 ложно — поэтому сработает ветка else, а не «знаковое сравнение»
    if (-1 < u) puts("знаковое сравнение");     // НЕ напечатает!
    else        puts("оба беззнаковые");        // напечатает

    int i = INT_MAX;
    // i + 1 — переполнение знакового, UB; компилятор вправе сделать что угодно
    (void)i;                                    // подавляем -Wunused-variable
    unsigned w = UINT_MAX;
    printf("%u\n", w + 1u);                     // 0 — беззнаковое заворачивается
    return 0;
}

• Переполнение знаковых целых — неопределённое поведение (UB), а не «заворот»: компилятор с -O2 может, например, «доказать», что x + 1 > x всегда, и выбросить проверку if (x + 1 < x). Почему это опасно на практике: компилятор реально выкидывает проверки переполнения в цикле или оптимизирует if (x + 1 < x) handle_overflow(); так, что ветка обработки никогда не вызывается — и баг проявляется только при смене версии компилятора. Как защищаться: беззнаковая арифметика, __builtin_add_overflow из GCC/Clang, переход на безопасные библиотеки вроде SafeInt или переписывание алгоритма через «предсказываемое» переполнение с проверкой до операции.
• Переполнение беззнаковых определено стандартом: результат берётся по модулю 2^N, то есть UINT_MAX + 1u == 0u. Это активно используется в хеш-функциях и кольцевых буферах. Кольцевой буфер с индексами (i + 1) % size без знаковых типов тоже можно реализовать через (i + 1) & (size - 1), если size — степень двойки (побитовое И быстрее деления по модулю и не зависит от «медленного» деления).
• Деление на ноль и INT_MIN / -1 — UB: второе выражение математически даёт 2^(n-1), что не влезает в знаковый тип. Почему: деление на ноль знаковых — UB, потому что результата нет в принципе, а процессор вызывает аппаратное исключение; для беззнаковых — формально тоже UB, хотя на практике часто даёт исключение или мусор. Защищаться нужно явной проверкой if (b != 0) перед делением.
• Остаток в C определён так, что знак результата совпадает со знаком делимого: -7 % 2 == -1, а не 1. Для неотрицательного остатка применяют ((a % b) + b) % b. Почему так: в Си используется правило «усечение к нулю» (как в C++, Java, C#), а не «усечение к минус бесконечности» (как в Python и в математическом определении). Это часто путают с Python, где -7 % 2 == 1; запомните: «в Си знак идёт от делимого».
• Целочисленные повышения: char и short перед арифметикой повышаются до int, поэтому unsigned char c = 255; c + 1 даёт 256 (в int), а не 0. Это ещё одна ловушка, которую спрашивают вместе с переполнением. Почему так: это наследие ранних процессоров, у которых арифметика над байтами была неэффективной — компилятор всегда расширяет до int, чтобы можно было использовать полный набор команд. Похожее правило действует для обычных int в выражениях с long: если хоть один операнд long, второй тоже повышается до long, поэтому int x = 1; long y = x + 1L; — это уже long. Общее правило: тип результата — «самый широкий» из операндов, при равной ширине знаковый «проигрывает» беззнаковому (см. иерархию ниже).

Иерархия неявных преобразований (usual arithmetic conversions). Когда в одном выражении встречаются разные целые типы, компилятор по стандарту C выполняет преобразования в таком порядке:

1. Если один из операндов имеет ранг выше (long long > long > int), другой приводится к нему. Почему: цель — не потерять значимые биты более широкого типа.
2. Если ранги равны, но один знаковый, а другой беззнаковый того же размера — оба приводятся к беззнаковому. Почему: в беззнаковом типе того же размера гарантированно помещаются все значения знакового (плюс ещё столько же положительных), а в знаковый положительные «сверху» уже не влезут.
3. Если знаковый тип может представить все значения беззнакового — знаковый «побеждает», и беззнаковый приводится к нему (так unsigned int приводится к long, если на платформе long шире int). Почему: так сохраняется знаковость и не происходит «отравления» отрицательными значениями.
4. Иначе оба приводятся к беззнаковому того же размера, что и знаковый. Почему: это единственный безопасный вариант, когда оба типа одного размера, а беззнаковый шире по диапазону, чем знаковый.

Это правило часто объясняет, почему sizeof(int) == sizeof(long) (на 32-бит) приводит к UB в выражении вроде (unsigned int)(-1), а на 64-бит (где long шире) — нет: на 64-бит беззнаковое -1 безопасно превращается в знаковое long, потому что long шире. Практический совет: если пишете код, который должен работать на обеих моделях данных, избегайте сравнений unsigned и signed одного размера — лучше сразу приведите к int64_t/uint64_t.

Практические советы по защите от ошибок знаковости:

• Включайте предупреждения: -Wall -Wextra -Wsign-compare -Wconversion. GCC и Clang умеют находить большинство сравнений знаковых и беззнаковых и подсвечивать потенциально опасные приведения типов. Подсказка: -Wconversion особенно полезен — он ругается на неявные сужающие приведения и потерю знака.
• Используйте unsigned только для битовых операций и счётчиков, где отрицательные значения не имеют смысла (например, размер массива, количество байт, маски). Для индексов массива и количества элементов size_t — идиоматический выбор: он беззнаковый, его размер равен размеру указателя, и он подставляется в %zu.
• Не смешивайте signed и unsigned в одном выражении: это почти всегда сигнал об ошибке проектирования. Почему: смешение «молча» меняет тип операнда и превращает -1 < 1u в ложь, что ломает интуитивную логику программы. Если приходится смешивать (например, API требует int, а вычисления идут в size_t), делайте явное приведение с комментарием «почему здесь безопасно» — это страхует и вас, и ревьюера.
• Проверяйте результат getchar() через int, а не через char: char не различает EOF и символ 0xFF. Классическая ловушка: функция возвращает int именно для того, чтобы вместить и EOF, и любой байт.

Вещественные числа, IEEE 754 и машинный эпсилон

Простыми словами.

Определения для старта.

• Вещественное число (число с плавающей точкой, floating-point) — приближённое представление действительного числа в памяти компьютера; всегда хранится с округлением, потому что битов конечное число. Аналогия: линейка с делениями через равные промежутки — очень маленькое и очень большое значение на ней либо не помещается, либо теряет точность.
• Мантисса (significand, fraction) — значащие цифры числа, то есть то, что в десятичной записи стоит до «× 10^k» (в IEEE 754 хранится в нормализованном виде как 1.xxxx…). Аналогия: это «полезная нагрузка» числа — именно она определяет, насколько точно мы знаем значение.
• Порядок (экспонента, exponent) — степень, на которую сдвигается «запятая» в мантиссе; в IEEE 754 хранится со смещением (bias), чтобы можно было сравнивать порядки как обычные целые. Аналогия: это «разряд» линейки — миллиметры, сантиметры или метры.
• IEEE 754 — международный стандарт, описывающий, как именно биты кодируют знак, порядок и мантиссу для float, double и long double. Именно поэтому результат вычислений одинаков на любом процессоре, который его поддерживает. Почему это важно: без единого стандарта одна и та же программа на x86 и на PowerPC давала бы разные ответы — а это катастрофа для переносимости научных и инженерных расчётов.

Вещественное число в памяти — это «научная запись с фиксированным числом значащих цифр», как 1.23·10^5. Часть битов хранит значащие цифры (мантисса), часть — порядок (насколько сдвинуть запятую), один бит — знак. Почему именно так: научная запись естественно ложится на двоичную систему, а раздельное хранение мантиссы и порядка позволяет охватить огромный диапазон значений при умеренной точности. Беда в том, что привычная десятичная дробь 0.1 в двоичной системе бесконечна, поэтому хранится с округлением — отсюда знаменитое 0.1 + 0.2 != 0.3. Аналогия: вещественный тип — это линейка с ограниченным числом делений; очень маленькое и очень большое число на ней либо не помещается, либо теряет точность. Другая бытовая аналогия: деньги в кошельке можно хранить только с точностью до копейки, поэтому «1/3 рубля» — это всегда округлённые 33 копейки, и при сложении трёх таких округлений никогда не получится ровно рубль.

Почему 0.1 + 0.2 != 0.3? В двоичной системе 0.1 записывается как бесконечная периодическая дробь 0.0001100110011…. 52 бита мантиссы double обрезают её до 52 значащих двоичных цифр, и реально 0.1 хранится как 0.10000000000000000555…. Складывая два таких округлённых числа, получаем 0.30000000000000004…, что не совпадает с округлённым 0.3 (0.29999999999999999…). Почему это не баг: это неизбежное следствие конечности битового представления — ни один конечный набор битов не может точно закодировать бесконечную дробь, как ни одно конечное число «33 копеек» не равно в точности трети рубля.

По стандарту IEEE 754 число хранится как знак, порядок со смещением и мантисса: float — 1 + 8 + 23 бита (смещение 127), double — 1 + 11 + 52 бита (смещение 1023). Отсюда «странности» вида 0.1 + 0.2 != 0.3. Дополнительно: в нормализованных числах старший бит мантиссы всегда равен единице, поэтому он явно не хранится — это экономит один бит точности (фактически 24 и 53 бита). Почему так: нормализация гарантирует единственное представление каждого числа и позволяет всегда иметь «единицу» перед точкой. Существуют ещё денормализованные (subnormal) числа — очень маленькие, у которых старший бит равен нулю: они дают плавный переход к нулю, но работают медленнее и с пониженной точностью. Зачем они нужны: без subnormal был бы разрыв между минимальным нормализованным числом и нулём — и a - a могло бы давать ненулевой результат.

#include <stdio.h>
#include <float.h>   // FLT_EPSILON, DBL_EPSILON, DBL_DIG, FLT_MAX
#include <math.h>    // fabs; при сборке не забудьте ключ -lm

int main(void) {
    double a = 0.1 + 0.2, b = 0.3;
    // Печатаем 17 знаков после точки: видно, что a не равно b ни на бит
    printf("%.17f %.17f равны? %d\n", a, b, a == b);   // 0 — не равны
    // Правильная проверка — не ==, а сравнение модуля разности с эпсилоном
    printf("fabs(a-b) = %.1e < DBL_EPSILON? %d\n",
           fabs(a - b), fabs(a - b) < DBL_EPSILON);
    // Эпсилон показывает относительную точность: у float хуже, чем у double
    printf("FLT_EPSILON=%.3e DBL_EPSILON=%.3e\n", FLT_EPSILON, DBL_EPSILON);
    // DIG — сколько десятичных цифр гарантированно точны
    printf("DIG=%d DBL_DIG=%d FLT_MAX=%.3e\n", FLT_DIG, DBL_DIG, FLT_MAX);
    return 0;
}

• Машинный эпсилон — минимальное ε, при котором 1.0 + ε != 1.0 (FLT_EPSILON ≈ 1.19·10⁻⁷, DBL_EPSILON ≈ 2.22·10⁻¹⁶). Это мера относительной точности: у double она примерно на 9 десятичных цифр лучше, поэтому в расчётах по умолчанию берут double, а float — для экономии памяти (например, больших массивов графики или GPU-буферов). Почему именно такое определение: эпсилон показывает, насколько относительное изменение числа перестаёт менять его «битовое представление». Теоретически DBL_EPSILON ≈ 2⁻⁵² — предел относительной погрешности округления, а DBL_DIG ≈ 15 — гарантированное число точных десятичных цифр, которые можно хранить и читать без потерь.
• Особые значения: ±0, ±∞ (INFINITY), NaN. Свойства: NaN != NaN (проверять только через isnan(), потому что сравнение всегда ложно — это сделано специально, чтобы NaN не «равнялся» ничему разумному), бесконечность получается делением ненулевого на ноль, а 0.0/0.0 даёт NaN. Ловушка: NaN «заразен» — любая арифметическая операция с NaN даёт NaN, поэтому сбой в одном месте отравляет весь дальнейший расчёт, и отлаживать его приходится от конца к началу, печатая промежуточные значения и проверяя их isnan().
• Вещественные нельзя сравнивать на точное равенство — только с допуском: fabs(a - b) < 1e-9. На экзамене уточните, что абсолютный допуск годится для чисел порядка единицы, а для больших значений берут относительный: fabs(a - b) < 1e-9 * fabs(b) (или fmax(fabs(b), ε) для защиты от нуля). Типичная ошибка: писать fabs(a - b) < 1e-9 при a ≈ 1e15 — для таких чисел относительная погрешность уже огромна (около 1), и условие будет ложным, даже когда числа «одинаковы» по физическому смыслу.
• Катастрофическая потеря точности: вычитание близких чисел (например, 1.0000001 - 1.0) обнуляет значащие разряды, а суммирование большого ряда маленьких чисел накапливает ошибку — на практике числа сортируют по модулю или применяют компенсационное суммирование Кахана. Почему так: при вычитании близких чисел старшие разряды мантиссы взаимно уничтожаются, и в результате достоверными остаются только младшие разряды, где как раз живёт ошибка округления — фактически мы «выбрасываем» точные биты и оставляем шум.
• Формат вывода: в printf float повышается до double (потому что float всегда приводится к double через variadic-аргументы), поэтому и %f, и %lf печатают double; %Lf — только для long double. В scanf это правило не действует: там float требует строго %f, а double — %lf, и перепутать их означает записать в память мусор (потому что scanf пишет в переменную и должен знать её реальный размер). Экзаменационный тезис: правило «в printf %f и %lf взаимозаменяемы, в scanf — нет» любят давать как задачу со звёздочкой.

Типичные ошибки.

• Сравнивать double через == — нельзя никогда (даже для значений вроде 1.0, потому что компилятор вправе соптимизировать выражение и свернуть его в 1, что иногда «помогает», а иногда ломает логику). Почему: стандарт IEEE 754 разрешает компилятору любое «безопасное» преобразование, и x == 1.0 после подстановки констант превращается в true, даже если x получился из вычислений с округлением.
• Использовать «магическое» 1e-9 как универсальный допуск — для очень больших и очень маленьких чисел оно не работает, берите относительный допуск eps * fmax(fabs(a), fabs(b)) или DBL_EPSILON * scale.
• Забывать -lm при использовании fabs, sqrt, sin — линкер выдаст undefined reference to fabs, потому что математические функции лежат в отдельной библиотеке libm, которая не подключается автоматически.
• Считать FLT_EPSILON «самым маленьким представимым числом» — нет, это относительная погрешность; минимальное положительное нормализованное число — FLT_MIN (≈ 1.17·10⁻³⁸), а субнормальные идут ещё ниже, вплоть до ~1.4·10⁻⁴⁵.
• Проверять NaN через x == NaN или x != x — стандарт гарантирует только isnan(x); хотя x != x на практике работает на всех распространённых платформах, это не переносимо и не идиоматично.
• Складывать double и int без приведения — на самом деле это безопасно (int повышается до double), но обратное (double)x к int обрезает дробную часть и может дать переполнение — это UB.

Экзаменационные тезисы.

1. Основной вещественный тип — double; float используется только ради экономии памяти и совместимости с GPU/графическими API.
2. IEEE 754 описывает «знак + порядок со смещением + мантисса»; для float это 1+8+23, для double 1+11+52. Старший бит мантиссы в нормализованных числах не хранится (неявная единица).
3. Машинный эпсилон — мера относительной точности: DBL_EPSILON ≈ 2.22·10⁻¹⁶, FLT_EPSILON ≈ 1.19·10⁻⁷. DBL_DIG ≈ 15 — гарантированное число точных десятичных цифр.
4. Сравнение == для вещественных запрещено; используется допуск — абсолютный (fabs(a-b) < eps) или относительный (fabs(a-b) < eps * fmax(fabs(a), fabs(b))).
5. Особые значения: ±0, ±∞, NaN; NaN != NaN, проверяется только isnan(). NaN «заразен» — любая операция с ним даёт NaN.
6. В printf %f и %lf эквивалентны (обе печатают double), в scanf — нет (требуется строгое соответствие типу); для long double используется %Lf.
7. Катастрофическая потеря точности возникает при вычитании близких чисел и при суммировании ряда с большой разницей масштабов — применяют суммирование Кахана или сортировку слагаемых.

Символы и таблица ASCII

Простыми словами. Компьютер «не знает» букв — он умеет хранить только целые числа. Договорились, что числу 65 соответствует буква 'A', числу 48 — символ '0', и так далее. Эта договорённость называется кодировкой, а конкретная историческая таблица для английского алфавита и цифр — ASCII. Понимание этой договорённости — ключ к половине строковых задач на экзамене.

Определения для старта.

• char — целочисленный тип размером ровно 1 байт (обычно 8 бит), в котором хранится код символа по некоторой кодировке. По сути это просто маленькое целое число, которое «по традиции» называют символом.
• ASCII — таблица кодировки, в которой символам английского алфавита, цифрам и управляющим кодам сопоставлены числа от 0 до 127. Это 7-битная таблица, она помещается ровно в один байт (старший бит всегда 0), поэтому ASCII-коды никогда не бывают отрицательными.
• Юникод (Unicode) — современная кодировка, охватывающая символы почти всех письменностей мира (более 140 тысяч символов на 2024 год); кодовая точка Unicode — это просто число от 0 до огромного значения, а как именно оно записывается в память, определяется формой кодирования (UTF-8, UTF-16, UTF-32).
• UTF-8 — самый популярный «переносимый» вариант Unicode, где символы могут занимать от 1 до 4 байт в зависимости от номера: ASCII-символы — 1 байт, кириллица — 2 байта, многие азиатские иероглифы — 3 байта, редкие символы и эмодзи — 4 байта.
• CP1251 — устаревшая однобайтовая кодировка для русского языка в Windows; в ней русские буквы лежат «не подряд» — отсюда многие старые баги и несовместимости, когда программа, написанная под CP1251, встречает UTF-8.

char — это на самом деле целое число размером 1 байт, которое договорились считать символом по таблице кодировки ASCII. Отсюда приём, который постоянно нужен на контрольных: символ цифры '7' и число 7 различаются на код нуля, поэтому '7' - '0' == 7. Аналогия: символ — это номер ячейки в таблице, а «превратить символ в цифру» — значит вычесть номер первой ячейки. Другая бытовая аналогия: код символа — это «адрес» в типографии: 'A' живёт по адресу 65, 'a' — по адресу 97, и разница всегда постоянна, потому что таблица устроена иерархически. Третья аналогия: представьте себе многоэтажный дом, где на каждом этаже живут «похожие жильцы» — на этаже 65–90 заглавные латинские буквы, на этаже 97–122 строчные, на этаже 48–57 цифры. Этажи не перепутаны, поэтому если вы знаете номер этажа, вы точно знаете, к какому семейству относится жилец.

char — целый тип размером 1 байт, хранящий код символа. Кодировка ASCII: 0–31 — управляющие (табуляция, перевод строки, звуковой сигнал и т. п.; их редко используют напрямую), 32 — пробел, 48–57 — цифры '0'..'9', 65–90 — 'A'..'Z', 97–122 — 'a'..'z', 127 — DEL. Мнемоника кодов: '0' — 48, 'A' — 65, 'a' — 97; разница между заглавной и строчной латинской буквой всегда 32 ('a' - 'A' == 32), а маленькие и большие буквы каждой группы идут подряд. Почему именно такие числа? ASCII разрабатывался так, чтобы коды букв и цифр были удобны поразрядно: смена регистра меняет ровно один бит (0x20, то есть шестой бит), а перевод цифры в число сводится к вычитанию одного и того же смещения '0'. Поэтому «табличные» операции делаются одной арифметической инструкцией — это было важно в 1960-х, когда процессоры были медленными, и сегодня остаётся важным «по привычке» и по совместимости с огромным массивом существующего кода. Дополнительная деталь: ASCII-коды в двоичном виде красиво ложатся на границы полубайт — '0' = 0011 0000, 'A' = 0100 0001, 'a' = 0110 0001, — что упрощает побитовые проверки вида «это цифра?» через маску 0xF0 == 0x30.

#include <stdio.h>
#include <ctype.h>   // toupper, tolower, isdigit, isalpha

int main(void) {
    char c = '7';
    int digit = c - '0';                 // 7 — перевод символа в число (вычитаем код '0')
    char upper = (char)toupper('a');     // 'A' — приведение нужно: toupper возвращает int
    // 'A' + 25 — это 'Z'; печатаем символ и его код
    printf("%d %c %c код=%d\n", digit, upper, (char)('A' + 25), (int)'A');
    return 0;
}

Полезно помнить: 'a' - 'A' == 32, цифры и латинские буквы идут подряд. Это позволяет без таблицы проверять регистр: if (c >= 'A' && c <= 'Z') c += 32;. Русские буквы в однобайтовой кодировке (CP1251) подряд не идут, а в UTF-8 занимают 2 байта — strlen вернёт длину в байтах, не в символах. Поэтому «посчитать русские буквы» через isalpha из стандартной библиотеки не получится: понадобится либо явная таблица CP1251, либо разбор UTF-8 по старшим битам. Техническая деталь: UTF-8-код русской буквы начинается с битов 110xxxxx (первый байт) и 10xxxxxx (второй), поэтому продвинутая проверка идёт побитово: (c & 0xC0) == 0xC0 означает «это начало многобайтового символа», а (c & 0x80) == 0 — «ASCII-символ». Полная картина для UTF-8: 0xxxxxxx — 1 байт (ASCII), 110xxxxx 10xxxxxx — 2 байта, 1110xxxx 10xxxxxx 10xxxxxx — 3 байта, 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx — 4 байта. Ещё одна ловушка: char может быть знаковым, и для байтов с кодом больше 127 (русские буквы) его нужно приводить к unsigned char, иначе toupper/isdigit получат отрицательное значение — формально UB. Почему так: функции <ctype.h> принимают int, но требуют, чтобы значение было либо EOF (обычно -1), либо представимо как unsigned char. Любой «отрицательный» char (например, русская буква в CP1251) формально нарушает контракт и приводит к неопределённому поведению — на практике чаще всего к «не тем» ответам (вроде «все кириллические буквы — это управляющие символы»). Практический приём: всегда оборачивайте вызовы вроде toupper((unsigned char)c) — это и безопаснее, и переносимее.

Типичные ошибки.

• Сравнивать '7' == 7 — никогда не сработает: это код символа (55) и число (7). Числа и символы — разные сущности; даже если их значения иногда совпадают (например, символ с кодом 7 — это '\a', а не цифра 7).
• Писать if (c >= 'A' && c <= 'Z') без приведения к unsigned char — для русских букв «зацепит» отрицательные значения, и условие может сработать «не там». Безопаснее: if ((unsigned char)c >= 'A' && (unsigned char)c <= 'Z').
• Считать, что strlen вернёт «число символов» — для UTF-8 вернётся число байт; например, длина строки «привет» — 12, а не 6. То же самое верно для sizeof — он меряет байты, а не «элементы», которые вы имели в виду.
• Применять toupper/tolower к русским буквам — стандартная библиотека работает только с ASCII-буквами; кириллица не изменится (или, что хуже, «превратится» во что-то по локали, если вы забыли setlocale(LC_ALL, "")).
• Сравнивать char с int без приведения — на некоторых платформах char знаковый, и русская буква в CP1251 даст отрицательное число, которое при сравнении поведёт себя не так, как вы ожидаете.
• Забыть, что '0' + i — это код цифры, а не само число; путаница между «символом-цифрой» и «числом-цифрой» — классика экзамена.

Зачем это на экзамене. Задачи «перевести строку в верхний регистр», «посчитать цифры в тексте», «проверить, что символ — буква» встречаются почти всегда. Умение работать с кодами символов напрямую (без toupper) ценят на МИФИ, где библиотеку ctype.h могут запретить. Приём для экзамена: запомните три ключевые константы — '0' == 48, 'A' == 65, 'a' == 97 — и умейте за минуту восстановить по ним всю таблицу, а также вывести формулу перевода цифры в число (c - '0') и смены регистра (c + 32 или c - 32). Дополнительная подсказка: '0' = 0x30, 'A' = 0x41, 'a' = 0x61 — кому-то легче помнить в шестнадцатеричной. И ещё: '9' - '0' == 9, поэтому формула c - '0' работает для всех цифр без исключений. На МФТИ любят задачи на побитовые операции с символами — например, проверить, чётная ли цифра, можно через (c & 1) == 0.

Классы памяти, области видимости и время жизни

Простыми словами. Когда вы объявляете что-то в программе, у этого «что-то» сразу появляется три характеристики: где оно лежит в памяти (стек, статическая область, регистр), как долго оно там лежит (до конца блока или до конца программы) и из каких мест кода к нему можно обращаться по имени. Эти три характеристики — класс памяти, время жизни и область видимости — независимы, и их путаница — главный источник ошибок у начинающих.

Определения для старта.

• Класс памяти (storage class) — категория переменной, описывающая, где она лежит в памяти и сколько живёт. В Си это auto, register, static, extern (плюс _Thread_local, но в учебных задачах это редкость).
• Область видимости (scope) — фрагмент исходного текста программы, где это имя доступно. Определяется тем, где в тексте стоит объявление (внутри блока, в файле, в параметрах функции).
• Время жизни (storage duration) — период выполнения программы, в течение которого под переменную реально занята память. Определяется тем, когда создаётся и уничтожается объект (на входе в блок, на старте программы, при malloc/free).
• Линковка (linkage) — возможность связать одно и то же имя в разных единицах трансляции (файлах); бывает внешняя (видна линкеру и доступна из других .c), внутренняя (видно только в своём .c) и «никакая» (только внутри своего блока).

Класс памяти отвечает на два разных вопроса: где переменная лежит (стек или статическая область) и сколько живёт (до конца блока или до конца программы). Не путайте с типом: тип говорит, что за значение, а класс памяти — где и как долго. Аналогия: область видимости — это «из каких комнат видно эту вещь», а время жизни — «сколько эта вещь вообще существует»; лампочка в коридоре видна из коридора (видимость), но горит, пока не выключат (время жизни). Другая бытовая аналогия: класс памяти — это «прописка» переменной: auto живёт в гостинице до выезда из { }, а static прописана в квартире навечно до конца программы. Третья аналогия: представьте себе многоквартирный дом-программу. auto-переменные — это съёмщики: приехали (вошли в блок), пожили, уехали (вышли из блока). static — это собственники квартир: въехали один раз при заселении дома (запуск программы) и живут до его сноса (завершение программы). А extern — это «прописанный у родственника в другом городе»: его нет в вашем файле, но вы знаете его адрес и можете позвонить.

Что важно из таблицы. Ключевое слово static перегружено: у локальной переменной оно продлевает жизнь, а у глобальной — наоборот, сужает видимость до одного файла. По умолчанию локальные переменные — auto (на стеке), а глобальные функции и переменные — extern (видны всем, кто подключил объявление). Слово register сегодня почти не влияет на код — компилятор сам решает, что класть в регистр, — но на экзамене его спрашивают как «подсказку, которую оптимизатор вправе игнорировать» и напоминают, что адрес у register-переменной брать нельзя. Почему static имеет два смысла? Исторически слово означает «объект с фиксированным положением в памяти»: для локальной переменной это «не на стеке, живи постоянно», а для глобальной — «спрячь от линкера, не экспортируй наружу». Общее в обоих случаях только то, что объект кладётся в статическую область данных (сегмент .data для инициализированных, сегмент .bss для нулевых). Конкретный сегмент определяется наличием инициализатора: static int x = 0; — в .bss (даже если инициализатор ноль!), а static int x = 5; — в .data. Компилятор сам выбирает, и с точки зрения языка разницы нет.

#include <stdio.h>

static int counter = 0;      // глобальная static: видна только в этом .c (внутренняя линковка)

int next(void) {
    static int calls = 0;    // локальная static: инициализируется ОДИН раз, живёт всю программу
    counter++;               // поэтому значение calls сохраняется между вызовами
    return ++calls;          // 1, затем 2, затем 3
}

int main(void) {
    // ВНИМАНИЕ: порядок вычисления аргументов printf не определён стандартом,
    // поэтому не полагайтесь на него: счётчики могут напечататься в любом порядке
    printf("%d %d %d counter=%d\n", next(), next(), next(), counter);
    return 0;   // параметры printf вычисляются в неопределённом порядке
}

• Область видимости — где доступно имя; время жизни — пока занята память. Это разные понятия, и их путают чаще всего: указатель на локальную переменную «виден», но после выхода из функции указывает на уже освобождённую память. Аналогия: адрес бывшего жильца — бумажка остаётся у вас (видимость имени), но за дверью уже никто не живёт (память освобождена). Экзаменационный вопрос-ловушка: «адрес какой переменной можно безопасно вернуть из функции?» — только статической или глобальной. Возврат адреса локальной переменной — это «классический» пример неопределённого поведения: формально код компилируется, но при попытке использовать указатель может произойти что угодно — от тихой ошибки до повреждения стека.
• Локальная static инициализируется нулём и не исчезает при выходе из функции: это законный способ хранить состояние между вызовами (счётчики, кеши, «одноразовая» инициализация). Тонкость: инициализатор у static вычисляется один раз, поэтому static int x = f(); гарантирует, что f будет вызвана ровно один раз — этим пользуются для отложенной инициализации и реализации «потокобезопасного» синглтона в однопоточной программе. Это безопаснее, чем «голый» if (first) { first = 0; ... }, потому что инициализация атомарна с точки зрения наблюдателя.
• Глобальная static даёт внутреннюю линковку — символ не виден линкеру из других единиц трансляции. Это инструмент сокрытия: так прячут вспомогательные функции, чтобы не конфликтовать именами в большом проекте. Зачем это вообще нужно? Без static имя попадает в таблицу символов и может случайно совпасть с таким же именем в другой библиотеке, что приведёт к ошибке линковки multiple definition; static говорит линкеру «не экспортируй это имя наружу», и конфликт невозможен. Именно поэтому во всех современных гайдлайнах рекомендуют объявлять «приватные» функции и переменные файла как static.
• extern — это объявление, а не определение: оно говорит «такая переменная есть где-то в другом файле». Классическая ошибка — написать extern int x = 5;; так делать можно, но обычно extern применяют без инициализации, а определение дают ровно в одном .c. Аналогия: extern — это «объявление гостя, что у хозяина дома есть сахар»: сахар лежит у хозяина, гости знают, что можно взять, но сам сахар не считают своим. Заголовочный файл с extern int x; — это «визитная карточка» гостя: имя известно всем, кому показали визитку, но сам объект по-прежнему живёт в одном-единственном месте.
• Статические объекты попадают в сегмент данных (инициализированные) или bss (нулевые), а не на стек, поэтому переполнить ими стек нельзя — но и освободить их вручную тоже нельзя. Где это видно: размер сегментов показывает утилита size(1); туда попадают глобальные и статические переменные, которым компилятор не дал начального значения. Это же объясняет, почему программа с огромным static char buf[1<<30] не запустится — лимит на размер .bss обычно ниже, чем на стек.

Типичные ошибки.

• Возвращать из функции адрес локальной переменной — классический пример «висячего указателя» (dangling pointer): указатель формально валидный, но разыменование даёт мусор или мусор в квадрате. Безопасный аналог — вернуть malloc-указатель или адрес static-переменной.
• Писать static int x; в заголовочном файле — каждая единица трансляции получит свою копию x, изменения в одном файле не будут видны в другом, что приводит к трудноуловимым ошибкам «почему счётчик не растёт». В заголовочном файле можно объявлять extern int x;, но определять через static — категорически нельзя.
• Путать extern и static: static прячет символ от других файлов, extern объявляет его в других файлах — это противоположные действия. Мнемоника: extern → экспорт наружу, static → закрыт внутри файла.
• Считать, что локальная static инициализируется при каждом вызове функции — нет, только один раз; последующие вызовы «пропускают» инициализатор. Если вам нужно «сбрасывать» значение на каждом входе — используйте обычную auto-переменную.
• Забыть, что register запрещает взятие адреса — компилятор выдаст ошибку address of register variable requested. Это историческое ограничение, до сих пор соблюдаемое стандартом.
• Думать, что глобальная переменная «живёт с момента объявления» — на самом деле она живёт с момента запуска программы, даже если объявление стоит в середине файла; компилятор всё равно разместит её в начале сегмента.

Экзаменационные тезисы.

1. Локальные переменные по умолчанию имеют класс auto: лежат на стеке и живут до конца блока. Слово auto можно писать, но это избыточно — компилятор и так считает все локальные auto.
2. static у локальной переменной продлевает жизнь до конца программы, у глобальной — сужает область видимости до одного файла. Два эффекта, одно ключевое слово — главный источник путаницы.
3. extern — это объявление без выделения памяти; определение (с инициализацией) должно быть ровно одно на всю программу. Иначе — multiple definition на этапе линковки.
4. register — подсказка компилятору; адрес такой переменной брать нельзя, в реальности компилятор часто игнорирует подсказку (всё равно раскладывает по регистрам то, что считает нужным).
5. Область видимости и время жизни — разные понятия: первое про текст программы, второе про время её выполнения. Классический пример расхождения — указатель на локальную переменную: имя в тексте есть, а памяти уже нет.

Препроцессор

Простыми словами. Препроцессор — это отдельная мини-программа внутри компилятора, которая работает до самого компилятора и занимается только текстом: она ничего не знает о типах, переменных и функциях, а просто механически копирует, заменяет и вырезает куски исходного кода. Аналогия: представьте, что вы пишете письмо с сокращениями («С уважением, И.»), а перед отправкой секретарь раскрывает все сокращения в полные слова — это и есть работа препроцессора; компилятор видит уже «развёрнутое» письмо и думает, что так оно и было написано. Главное следствие: ошибки препроцессора выглядят странно (компилятор ругается на несуществующие строки и имена), потому что он видит результат подстановки, а не ваш исходный текст. Полезный инструмент отладки — флаг компилятора -E (только препроцессор) или -save-temps (сохраняет промежуточные файлы): с ними можно увидеть, во что превратился ваш код после всех #include и #define.

Препроцессор работает до компилятора и оперирует текстом: подставляет файлы, раскрывает макросы, отбирает код по условиям. Эти три действия — #include (вставить файл), #define (объявить подстановку), #if/#else/#endif (условно оставить или выбросить куски) — составляют 95% всей препроцессорной рутины.

#include <stdio.h>

// Скобки вокруг параметра И вокруг всего выражения обязательны:
// без них SQUARE(2+3) превратится в 2 + 3 * 2 + 3 = 11 вместо 25.
#define SQUARE(x) ((x) * (x))
#define MAX(a, b) ((a) > (b) ? (a) : (b))
#define STR(x)    #x                        // строкификация: STR(abc) -> "abc"
#define CAT(a, b) a##b                      // склейка токенов: CAT(var, 1) -> var1

#if defined(__linux__)                     // условная компиляция по платформе
    #define OS "Linux"
#elif defined(_WIN32)
    #define OS "Windows"
#else
    #define OS "Unknown"
#endif

int main(void) {
    int CAT(var, 1) = 42;                   // на этапе препроцессинга станет var1 = 42
    printf("%d %d %s var1=%d\n", SQUARE(3), MAX(4, 7), OS, var1);
    return 0;
}

Простыми словами. Препроцессор — это отдельная программа, которая запускается до компилятора и работает исключительно с текстом: она читает ваш .c-файл, ищет строки, начинающиеся с #, и выполняет указанные в них текстовые преобразования. Результат её работы — «чистый» текст на Си без директив, который уже видит компилятор. Аналогия: препроцессор — это корректор в издательстве, который перед печатью убирает служебные пометки и расставляет стандартные шаблоны, а компилятор — это типография, которой до пометок уже нет дела. На экзамене важно понимать: препроцессор не знает ни типов, ни переменных, ни областей видимости — это просто текстовый процессор, и именно в этом корень большинства «магических» ошибок Си.

• Директивы: #include, #define, #undef, #if/#ifdef/#ifndef/#else/#elif/#endif, #error, #pragma, #line. Все они начинаются с # в начале строки (после необязательных пробелов и табуляций) и завершаются переводом строки — поэтому длинные макросы переносят через обратный слэш \, который «склеивает» следующую строку с текущей. **Почему именно так:** препроцессор задумывался как простой текстовый процессор, и перевод строки для него — естественный разделитель команд (как точка с запятой для компилятора). Обратный слэш в конце строки буквально говорит: «следующую строку не считай новой командой, приклей её к моей». **Практический совет:** перед \ не должно быть ни пробелов, ни комментариев — иначе склейка не сработает, и компилятор выдаст непонятную ошибку далеко от места проблемы. Отладочный приём: посмотреть результат препроцессора можно флагом gcc -E file.c — на экране появится уже «развёрнутый» файл без единой директивы.

• Двойное вычисление аргументов макроса — главная ловушка: MAX(i++, j) увеличит i лишний раз, потому что параметр a подставляется в текст дважды (и в условии, и в результате), и i++ выполнится дважды. Как это работает «под капотом»: препроцессор не понимает выражений — он просто текстово заменяет каждый формальный параметр на то, что вы передали. Поэтому MAX(i++, j) буквально превращается в ((i++) > (j) ? (i++) : (j)), и i++ встречается дважды в тексте, а значит выполнится дважды в коде. Замена — static inline-функция, у которой аргументы вычисляются ровно один раз, есть проверка типов и которую отладчик видит в стеке вызовов. Экзаменационный тезис: «макрос — это текстовая подстановка, функция — это вызов с семантикой». Лайфхак: если очень хочется макрос без двойного вычисления, используют GCC-расширение __typeof__ или стандартный typeof (C23) вместе с временной переменной через выражение-запятую — но это уже признак того, что проще написать функцию.

• #include <...> ищет в системных каталогах (пути задаются компилятором и переменными среды вроде CPATH, C_INCLUDE_PATH), #include "..." — сначала рядом с текущим файлом, а потом уже в системных. Поэтому свои заголовки пишут в кавычках, а стандартные — в угловых скобках. Смешение стилей не ошибка, но нарушает договорённость и сбивает читателя. Аналогия: <...> — это «принеси из библиотеки» (путь известен системе), а "..." — это «возьми со стола рядом, а если нет — иди в библиотеку». Типичная ошибка новичка: #include "stdio.h" вместо #include <stdio.h> формально работает, но замедляет сборку на больших проектах — компилятор каждый раз проверяет текущий каталог, и только потом лезет в системные пути.

• Include guard (#ifndef NAME_H / #define NAME_H / #endif) защищает от повторного подключения и повторных определений при множественном #include; #pragma once делает то же самое короче, но не входит в стандарт C (хотя поддерживается GCC, Clang и MSVC). На экзамене безопаснее использовать guard — он переносим и стандартен. Почему guard работает: при первом включении файла макрос NAME_H ещё не определён, поэтому #ifndef пропускает содержимое, а #define его создаёт; при повторной попытке макрос уже есть, и #ifndef NAME_H сразу даёт false — всё содержимое файла пропускается целиком. Практический совет: имя guard-а должно совпадать с именем файла, быть в верхнем регистре и заканчиваться на _H (например, vector.h → VECTOR_H), иначе можно случайно пересечься с чужим макросом. Редкая ловушка: guard не спасает, если в двух разных заголовках случайно выбрано одно и то же имя — компилятор не выдаст ошибку, но один из заголовков «молча» окажется пустым.

• Полезные встроенные макросы: __FILE__ (имя файла в виде строки), __LINE__ (номер текущей строки) — вместе с __func__ (имя текущей функции, стандарт C99) дают бесплатную трассировку для отладки; __DATE__, __TIME__ фиксируют момент сборки (полезно в version); __STDC_VERSION__ помогает писать код под разные стандарты (например, 201112L для C11, 201710L для C18). Практический пример трассировки: #define LOG(msg) fprintf(stderr, "[%s:%d] %s\n", __FILE__, __LINE__, msg) — вызов LOG("starting") автоматически печатает имя файла и номер строки. Важный нюанс: __DATE__ и __TIME__ «зашиваются» в момент компиляции каждой единицы трансляции, поэтому в большом проекте разные .c могут показать разные timestamp-ы; для единой даты сборки используют отдельный сборочный скрипт и передают её через -D. Лайфхак на экзамене: если видите в условии задачи «номер строки, где произошла ошибка» — это почти всегда намёк на __LINE__ и __FILE__.

• Макрос не имеет типа и области видимости: #define N 10 заменит N везде — включая имена переменных, комментарии и чужие идентификаторы, если они случайно совпали. Поэтому имена макросов пишут ЗАГЛАВНЫМИ БУКВАМИ — так их видно в коде и сразу понятно, что это не переменная. Типовая ошибка: #define max(a, b) ... в системном заголовке ломает имена max в пользовательском коде — именно поэтому макросы в стандартной библиотеке давно заменены на шаблоны/функции. Экзаменационная подсказка: идентификатор ЗАГЛАВНЫМИ — это почти всегда макрос или константа времени компиляции; строчными с подчёркиваниями — функция или переменная. Ловушка с подчёркиванием: идентификаторы, начинающиеся с подчёркивания и заглавной буквы или с двух подчёркиваний подряд (__MY_MACRO), зарезервированы стандартом для реализации — не используйте их в своём коде, иначе рискуете пересечься с внутренностями компилятора или библиотеки и получить необъяснимый UB.

Структура программы и функция main

Простыми словами. Любая программа на Си — это набор функций, и ровно одна из них, main, служит точкой входа: с неё начинается выполнение. Аналогия: main — дирижёр, который даёт старт оркестру, а остальные функции — музыканты, каждый со своей партией; дирижёр не играет мелодию, он координирует. Аргументы argc/argv — это то, что вы дописали в командной строке после имени программы (./prog hello world → argc=3, argv={"prog","hello","world"}); код возврата main видит оболочка и может использовать в скриптах через $?. Что происходит после return: среда выполнения (операционная система или симулятор) получает целое число, и об этом числе можно строить логику в shell-скриптах: cmd; echo "exit=$?" или if ./prog; then ....

Программа — набор функций, точка входа — main, возвращающая int (код возврата доступен оболочке как $?).

#include <stdio.h>
#include <stdlib.h>   // EXIT_SUCCESS, EXIT_FAILURE

int main(int argc, char *argv[]) {
    // argc >= 1; argv[0] — имя программы; argv[argc] == NULL
    if (argc < 2) {
        // Диагностику пишем в stderr, а не в stdout: так её увидят даже при перенаправлении вывода
        fprintf(stderr, "Использование: %s <имя>\n", argv[0]);
        return EXIT_FAILURE;                 // обычно 1 — сообщаем об ошибке оболочке
    }
    printf("Привет, %s!\n", argv[1]);        // argv[1] — первый реальный аргумент
    return EXIT_SUCCESS;                     // 0 — успешное завершение
}

• Стандартные формы main: int main(void) (без аргументов) и int main(int argc, char *argv[]) (с аргументами). Написание void main() нестандартно: на некоторых компиляторах оно «работает», но это UB (undefined behavior), и на экзамене за него снижают оценку. Почему: стандарт C явно требует, чтобы реализация вызывала именно функцию с сигнатурой, возвращающей int — что возвращает void main, среда выполнения не знает, и в оболочку может уйти произвольный «мусор» из регистра. Тонкость: int main() и int main(void) — это разные вещи в Си: пустые скобки означают «аргументы не специфицированы» (K&R-наследие), а (void) — «аргументов нет точно». Всегда пишите (void), если функция ничего не принимает.

• В C99+ при отсутствии return в main неявно возвращается 0 (только для main! в других функциях это UB), но явный return нагляднее и переносимо читается — привыкайте писать его всегда. Лайфхак: в других функциях, возвращающих int, отсутствие return — это не «неявный ноль», а UB: компилятор может вернуть что угодно, и программа будет вести себя по-разному в debug- и release-сборке. Экзаменационная формулировка: «в Си main — единственная функция, которой разрешено fall off the end».

• Объявления прототипов нужны до вызова; заголовки (.h) хранят объявления, файлы реализации (.c) — определения. Отсюда типовые ошибки линковки: undefined reference to foo — определение не попало в сборку (забыли скомпилировать .c или не добавили в проект); implicit declaration of function — не подключён заголовок с прототипом, компилятор угадывает сигнатуру и может сгенерировать неверный код. Экзаменационная подсказка: «implicit — проблема компиляции, undefined — проблема линковки». Наглядный пример «implicit»: вызвали printf("%d", 3.14) без #include <stdio.h> — компилятор решит, что printf возвращает int (по умолчанию для неизвестных функций в старых стандартах), и на x86-64 передача double через регистры XMM сломается: вместо 3.14 напечатается мусор. В современных компиляторах это лечится -Wimplicit-function-declaration, который сразу скажет, где забыли #include.

• Точка входа — не синоним «вся программа»: код принято делить на функции, а main держать коротким (проверить аргументы, вызвать бизнес-логику, вернуть код). Это напрямую спрашивают на защите курсовой про модульность: «длинный main — признак плохой архитектуры». Хороший main — это 5–15 строк оркестровки, а вся работа — в вызываемых функциях. Практический совет: если ваш main не помещается на один экран — это сигнал к рефакторингу; выносите чтение аргументов, инициализацию, основной цикл и финальный отчёт в отдельные функции (parse_args, init, run, cleanup).

Операции и приоритеты

Простыми словами. Приоритет определяет, какая операция выполнится раньше (как в школе: умножение «сильнее» сложения); ассоциативность — как читать операции одного приоритета: слева направо (как в a - b - c = (a - b) - c) или справа налево (как в a = b = c = a = (b = c)). Мнемоника: «сначала скобки, потом унарные, потом арифметика, потом сравнения, потом логика, и только в самом конце — присваивание». Правило выживания на экзамене: если сомневаетесь в приоритете — ставьте скобки; лишние скобки никогда не считаются ошибкой, а вот «съеденный» приоритет — считается, и компилятор вас не спасёт. Главная ловушка: битовые операции (&, ^, |) имеют приоритет ниже, чем сравнения (==, !=), поэтому смешивать их в одном выражении без скобок — почти гарантированная ошибка.

Особенности и подводные камни:

• Целочисленное деление отбрасывает дробную часть (7 / 2 == 3, а не 3.5) — это частая ошибка новичков, которые пишут int x = a / b и ожидают дробный результат; для дробного нужен double и хотя бы один операнд типа double. Лайфхак-диагностика: если компилятор предупреждает «implicit conversion from double to int loses precision» — вы только что попались на эту ловушку. Правило: результат деления имеет тип «самый широкий из операндов», но если оба int — результат тоже int, сколько бы вы ни старались.
• && и || вычисляются с коротким замыканием: если результат уже известен по левому операнду, правый не вычисляется. Отсюда идиома if (p != NULL && *p > 0) — обращение к *p безопасно, потому что при p == NULL правая часть не запустится. Экзаменационный вопрос-ловушка: чем отличается & от &&? Первый — побитовое И (всегда вычисляет оба аргумента), второй — логическое И с коротким замыканием. То же для | и ||.
• = вместо == в условии — частая ошибка: пишите if (0 == x) или включайте предупреждения компилятора (-Wall -Wextra), он явно скажет «suggest parentheses around assignment used as truth value». Сравнение с нулём через 0 == x — старая защита от опечатки, потому что 0 = x не скомпилируется. Продвинутая защита: некоторые проекты запрещают присваивания в if через -Werror=parentheses или статические анализаторы (clang-tidy, cppcheck).
• *p++ — это *(p++), а не (*p)++: постфиксный ++ имеет более высокий приоритет, чем унарный *. Аналогия: представьте, что операторы тянут «руки» к операндам: постфиксный ++ хватает p раньше, чем * успевает к нему прикоснуться — поэтому сначала запоминается старое значение p, а потом указатель сдвигается. Это же поведение — фундамент всех итераторов по массивам в Си.

Как читать таблицу на практике. Три самые коварные строки — 2, 14 и 15. Строка 2 объясняет, почему *p++ разбирается как *(p++): постфиксный ++ стоит в отдельной, более высокой группе (1), чем унарный * (группа 2), поэтому сначала берётся «старое» значение, а потом указатель сдвигается. Строка 14 объясняет, почему a = b = c работает (присваивание правоассоциативно: сначала b = c, потом a = результат), а if (a = b) — почти всегда ошибка: = возвращает присвоенное значение, и условие окажется истинным при ненулевом b. Строка 15 напоминает, что запятая тоже оператор: int x = (1, 2); присвоит 2, потому что значение всего выражения с запятой — последний операнд. Без внешних скобок int x = 1, 2; — это не выражение с запятой, а объявление с ошибкой синтаксиса. Тонкость про запятую: оператор-запятая вводит точку следования (sequence point) между операндами, поэтому i = 0, i++, i++ гарантированно даст i == 2 после выполнения — побочные эффекты не «перемешиваются».

Шпаргалка по частым комбинациям:

Проверьте себя: 1 << 2 + 3 — это 1 << 5, потому что сложение приоритетнее сдвига, и в C это классический вопрос с подвохом. Если вы написали 1 << (2+3) = 32, а не (1<<2)+3 = 7 — вы усвоили таблицу. Экзаменационная ловушка: битовые операции (&, ^, |) имеют приоритет ниже, чем сравнения (==, !=), поэтому flags & MASK == 0 читается как flags & (MASK == 0) — почти наверняка не то, что имел в виду автор; всегда оборачивайте побитовые операции в скобки при смешивании с логикой. Ещё одна типовая ошибка: high << 8 + low — кажется, что это «склеивание» двух байт в 16-битное число, но на самом деле это high << (8 + low), что почти всегда бессмысленно; правильно писать (high << 8) | low.

Управляющие конструкции: if, switch, циклы

Простыми словами. Управляющие конструкции задают порядок выполнения: ветвление (if, switch) выбирает один из путей, а циклы (for, while, do-while) повторяют действия, пока условие истинно. Аналогия: ветвление — развилка на дороге, цикл — круговое движение, пока не появится съезд. На экзамене проверяют не только синтаксис, но и «прогон»: сколько раз выполнится тело цикла и что напечатает программа. Главный принцип: в Си нет отдельного булева типа как «первоклассного гражданина» — любое целое число может быть условием, поэтому понимание 0 vs «не ноль» важнее, чем знание синтаксиса if.

Что такое условие в Си. Условие в if, while, for — это обычное выражение языка C (например, x > 0, getchar() != EOF, arr[i]). Оно вычисляется, и результат трактуется как логическое значение: ноль — ложь (false), любое ненулевое значение — истина (true). Поэтому конструкции if (x), if (x != 0) и if (42) означают одно и то же: «выполнить тело, если x не равен нулю». Именно из-за этого правила так опасен оператор = вместо == — он присваивает, а не сравнивает, и результат присваивания сам становится значением условия. Лайфхак-диагностика: функция, возвращающая int, всегда может стоять в if без сравнения — if (malloc(size)) { ... } означает «проверяем, что указатель не NULL», потому что malloc возвращает NULL (== 0) при неудаче.

#include <stdio.h>

int main(void) {
    int score = 85;
    if (score >= 90)      puts("отлично");
    else if (score >= 70) puts("хорошо");
    else                  puts("нужно подтянуть");

    // switch работает только с целыми типами (включая char и enum)
    // и сравнивает на равенство; без break управление «проваливается»
    switch (score / 10) {
        case 10:
        case 9:  puts("A"); break;
        case 8:  puts("B"); break;
        default: puts("C"); break;
    }

    for (int i = 0; i < 3; i++) printf("%d ", i);   // 0 1 2
    putchar('\n');

    int k = 0;
    while (k < 2) printf("w%d ", k++);              // проверка ДО тела
    do { printf("d%d ", k); k--; } while (k > 0);   // тело выполнится хотя бы раз
    putchar('\n');

    for (int i = 0; i < 5; i++) {
        if (i == 1) continue;   // пропустить итерацию
        if (i == 4) break;      // выйти из цикла
        printf("%d ", i);       // 0 2 3
    }
    putchar('\n');
    return 0;
}

Как читать if сверху вниз. В цепочке if / else if / ... / else проверки идут по порядку сверху вниз, и выполняется ровно первая ветка, условие которой истинно. Все остальные пропускаются — даже если их условия тоже истинны. Простое определение: цепочка if/else — это «приоритетный список вариантов»: нашёл подходящий — обработал и вышел.

Аналогия из жизни: представьте, что вы — охранник в клубе и проверяете посетителей по списку приглашений. Вы идёте по списку сверху вниз и пропускаете первого, кто прошёл проверку. Если «VIP» стоит выше «обычного гостя», то VIP пройдёт; если поменять порядок — все VIP будут идти по обычной очереди.

Почему порядок важен. Более строгое условие (score >= 90) ставят раньше менее строгого (score >= 70), иначе первое же совпадение «съест» все последующие случаи: студент с баллом 95 попадёт в ветку >= 70 и никогда не дойдёт до проверки >= 90. Совет: проверяйте порядок от частного к общему, как в матёрой логике вложенных интервалов.

Почему switch сравнивает только на равенство. В отличие от if, который может проверять любое выражение-условие (диапазон, комбинацию, вызов функции), switch принимает только целочисленное выражение (или char, enum, приводимые к int) и сравнивает его с метками case строго на равенство. Простое определение: switch — это «словарь значений»: ключ — ваше выражение, значения — константы в case. Никаких диапазонов и составных условий в самом case записать нельзя — приходится «раскрывать» их через серию case или использовать «проваливание» (fall-through).

Аналогия: switch — это домофон с кнопками 1, 2, 3; нажали одну — сработала одна функция. Нельзя запрограммировать «открыть дверь, если нажата любая кнопка с 1 по 9» одной меткой — только перечислением case 1: case 2: ... case 9: с проваливанием. Почему так: на аппаратном уровне компилятор часто превращает switch по плотным меткам в таблицу переходов (jump table) — массив адресов, где поиск за O(1). Для произвольных условий такая оптимизация невозможна.

• Условие любого цикла и if — это выражение; в Си «истина» = «не ноль». Поэтому if (x = 5) синтаксически корректно и всегда истинно: классическая ошибка, спасает идиома if (5 == x) (Yoda-условие).
• for удобен, когда число итераций известно заранее (счётчик от 0 до n), while — когда условие проверяется до тела и заранее число шагов неизвестно, do-while — когда тело обязано выполниться хотя бы раз (например, запрос ввода у пользователя или текстовое меню).
• break выходит из ближайшего цикла или switch, continue переходит к следующей итерации того же ближайшего цикла. Вложенные циклы одним break не прервать — нужен флаг (int found = 0;) или goto (в Си это не запрещено и иногда уместно, в отличие от C++-идиоматики).
• Типичная ошибка: цикл for (i = 0; i <= n; i++) при обращении к массиву из n элементов — лишняя итерация выходит за границы. Правильно — строго < n. Проверка в уме: «массив длины n имеет индексы 0..n-1, значит условие цикла — i < n».
• Ещё одна: бесконечный цикл while (i < n) без изменения i внутри тела или обратный цикл с беззнаковым счётчиком (for (size_t i = n-1; i >= 0; i--)): беззнаковое значение никогда не станет меньше нуля — после 0 идёт UINT_MAX, и условие снова истинно.

Разбор ошибок подробнее.

1. = вместо ==. Запись if (x = 5) означает «присвой x значение 5 и проверь результат». Так как 5 — ненулевое число, условие всегда истинно, а x молча перезаписан, теряя прежнее значение. Это одна из самых частых и опасных опечаток в Си. Компилятор часто выдаёт предупреждение warning: suggest parentheses around assignment used as truth value — не игнорируйте его. Защитная идиома «Yoda-условие» (if (5 == x)) помогает: если опечатка, то 5 = x не скомпилируется, потому что литералу нельзя присваивать. Аналогия: перепутали «взять» и «положить» в карман — Yoda говорит наоборот: «положи 5 в карман x», и ошибиться невозможно.

2. Граница массива i <= n вместо i < n. Если массив объявлен как int a[n], его допустимые индексы — от 0 до n-1. Условие i <= n добавляет лишнюю итерацию, в которой происходит чтение/запись a[n] — это выход за границы, классическое UB (undefined behavior). Компилятор не проверяет выход за массив, и программа может «работать» на вашем компьютере, но упасть на другом (или при включённой оптимизации). Правило-памятка: для массива длины n всегда i < n.

3. Беззнаковый обратный цикл. Тип size_t (а также unsigned, unsigned int) не может быть отрицательным: когда переменная равна 0, вычитание единицы даёт очень большое число (например, 0u - 1u == UINT_MAX для 32-битного типа). Поэтому условие i >= 0 для беззнаковой переменной всегда истинно — цикл становится бесконечным и либо зависает, либо читает чужую память. Безопасные варианты: использовать знаковый тип (int i;), либо цикл for (size_t i = n; i-- > 0; ) (идём от n до 1 и проверяем до декремента — i-- сначала возвращает текущее значение, потом уменьшает), либо цикл в прямом направлении.

4. Точка с запятой после if / while / for. Случайно поставленная ; делает ветку пустой: if (x > 0); printf("..."); напечатает строку безусловно, потому что точка с запятой завершает пустой оператор, а следующий printf уже не относится к if. Аналогия: как будто вы сказали «если дождь; иди гулять» — точка с запятой съела условие, и «иди гулять» стало самостоятельным предложением. Тот же эффект у while (x > 0); — пустое тело крутится, пока условие истинно, но ничего полезного не делает (часто именно так получают «горячий» цикл, грузящий процессор).

5. Пустое тело цикла while без прогресса. Если внутри while не меняется переменная из условия, цикл никогда не закончится и программа «зависнет». Это особенно опасно при копировании фрагментов — компилятор не обязан это ловить, потому что в общем случае переменная может меняться через указатель или внешнюю функцию. Совет: для каждого цикла мысленно отвечайте на вопрос «что приближает нас к выходу?».

6. Забытый break в switch. Без break управление «проваливается» в следующий case. Иногда это используют намеренно (как в примере для оценок A: case 10: без тела проваливается в case 9:), но случайный пропуск — частая причина неверной работы. Совет: после каждого case явно пишите либо break, либо комментарий /* fall-through */, чтобы было видно, что провал намеренный (современные компиляторы умеют ловить случайный fall-through при флаге -Wimplicit-fallthrough).

Экзаменационные тезисы (что нужно уметь отвечать).

• Условие в Си — выражение; истина трактуется как «не ноль», ложь — как ноль.
• if / else if / else выполняет ровно одну подходящую ветку, остальные пропускаются; порядок условий важен — от частного к общему.
• switch принимает только целочисленные типы и сравнивает на равенство; без break происходит fall-through.
• for — цикл со счётчиком; while — с предусловием; do-while — с постусловием (тело минимум один раз).
• break прерывает ближайший цикл/switch; continue начинает новую итерацию ближайшего цикла.
• Ошибка = вместо == — присваивание, не сравнение; защита — идиома Yoda if (5 == x).
• Выход за границы массива — UB; правильная граница цикла по массиву длины n — i < n.
• Беззнаковый счётчик неотрицателен: обратный цикл i >= 0 для size_t всегда истинен → бесконечный цикл.

Битовые операции

Простыми словами. Битовые операции работают не с числом целиком, а с каждым его битом независимо: & (И) оставляет единицы там, где они есть в обоих операндах, | (ИЛИ) — где есть хотя бы в одном, ^ (исключающее ИЛИ) — где биты различаются, ~ инвертирует все биты, а сдвиги <</>> двигают биты влево/вправо. Аналогия: это работа с набором выключателей на щитке — можно включать, выключать и проверять каждый отдельно, не трогая остальные. Применяются для флагов (набор логических признаков в одном числе), плотных массивов битов, быстрых умножений/делений на степень двойки, генерации хешей и низкоуровневых протоколов (сетевые заголовки, регистры устройств).

Почему это работает именно так. Память в компьютере хранится как последовательность битов, и процессор умеет выполнять логические операции над всеми битами слова одной машинной инструкцией (за один такт). Поэтому битовые операции — самый «дешёвый» способ проверить или изменить один признак: не нужно делить число на 10 и сравнивать остаток, достаточно выделить один бит маской. На уровне железа это и есть основной способ хранить состояние: «включён/выключен», «есть ошибка/нет ошибки», «доступ открыт/закрыт». Один 32-битный int может хранить 32 независимых флага — экономия памяти и сравнение всего за одну операцию &.

#include <stdio.h>

int main(void) {
    unsigned a = 0x0Fu;              // 0000 1111
    unsigned b = 0x33u;              // 0011 0011
    // %08x печатает 8 шестнадцатеричных цифр
    printf("%08x %08x %08x %08x\n", a & b, a | b, a ^ b, ~a);
    // a & b = 0000 0011, a | b = 0011 1111, a ^ b = 0011 1100

    unsigned flags = 0;
    flags |= (1u << 2);              // установить бит 2 (нумерация с нуля)
    flags &= ~(1u << 2);             // сбросить бит 2 через инверсию маски
    int is_set = (flags >> 2) & 1u;  // проверить бит 2
    printf("flags=%u is_set=%d\n", flags, is_set);

    // Полезные приёмы
    int x = 6;
    printf("чётность: %d, x*2: %d, x/2: %d\n", x & 1, x << 1, x >> 1);
    // Обмен без третьей переменной (для демонстрации; на практике читается хуже)
    int p = 3, q = 5;
    p ^= q; q ^= p; p ^= q;
    printf("p=%d q=%d\n", p, q);     // 5 3
    return 0;
}

Шпаргалка по маскам (на примере бита номер k).

Принцип «не трогать чужие биты». Любая корректная битовая операция над флагом должна оставлять все остальные биты неизменными. Именно поэтому для сброса используют & ~(1u << k), а не просто flags &= 0 или flags = 0: первая запись обнулит только целевой бит, остальные оставит как есть. Нарушение этого принципа — частая причина трудноуловимых багов: «я изменил только флаг, а сломалось всё». Аналогия: если вы меняете одну лампочку в гирлянде, остальные должны продолжать гореть, как горели.

• x & 1 — проверка нечётности (младший бит = 1 означает нечётное), x << 1 — умножение на 2, x >> 1 — деление на 2 (для беззнаковых), x & (x - 1) — сброс младшего установленного бита (классический трюк для подсчёта единиц в числе по алгоритму Брайана Кернигана).
• Типичные ошибки: сдвиг на число, большее или равное ширине типа, — UB; сдвиг знакового числа влево с переполнением — UB (и даже 1 << 31 для 32-битного int); смешивание логических &&/|| с битовыми &/| — это разные операции с разным приоритетом.
• Для флагов применяйте беззнаковый тип (unsigned), а маски пишите как 1u << k, чтобы не получить знаковый сдвиг и лишнее приведение типов.
• Удобный приём проверки нескольких бит сразу: if (flags & MASK) ... — работает, потому что результат & равен нулю, только если все проверяемые биты нулевые.

Разбор ошибок подробнее.

1. Сдвиг на величину ≥ ширины типа. Стандарт C не определяет поведение, если правый операнд << или >> больше или равен ширине типа левого операнда. Например, для 32-битного unsigned int сдвиг x << 32 — это UB. Безопасный сдвиг: правый операнд в диапазоне [0, ширина-1]. На практике компиляторы часто сворачивают такой сдвиг в «ничего не делать» или используют только младшие биты сдвига (например, x86 берёт x << (n % 32)), но полагаться на это нельзя — другой компилятор или режим оптимизации может дать другой результат.

2. Сдвиг знакового числа влево. Для знакового типа int сдвиг влево может изменить знаковый бит или привести к переполнению, что для знаковых типов считается UB. Именно поэтому выражение 1 << 31 опасно для 32-битного int — результат «не положительный, но и не отрицательный в обычном смысле» (формально UB, на практике часто получается INT_MIN). Привычка писать 1u << k страхует от этого: литерал 1u имеет тип unsigned int, и весь сдвиг выполняется в беззнаковой арифметике, где переполнение определено как взятие по модулю 2^N.

3. & vs &&, | vs ||. Битовые & и | всегда вычисляют оба операнда и работают с каждым битом независимо. Логические && и || вычисляют правый операнд только при необходимости (short-circuit, «короткое замыкание») и возвращают ровно 0 или 1. Пример разницы: x & y — побитовое И двух чисел (может вернуть любое число); x && y — «истина (1), если оба не равны нулю, иначе ложь (0)». Случайная замена одного на другое — классический источник UB, например if (ptr != NULL && *ptr > 0) корректно (разыменование только при ненулевом указателе), а if (ptr != NULL & *ptr > 0) — нет: *ptr будет вычислен всегда, и при NULL программа упадёт. Запомните: && и || — для логики, & и | — для битов.

4. ~ для знаковых чисел. Оператор ~ инвертирует все биты представления, включая знаковый. Для int это даёт «отрицательное число минус один» (~5 == -6, потому что работает формула ~x == -x - 1), что обычно не совпадает с интуитивным «логическим отрицанием». Для логического отрицания используют !, а не ~: !x вернёт 1, если x == 0, и 0 иначе; ~x инвертирует биты и почти всегда даст ненулевое значение (исключение — только x == -1, у которого все биты единичные).

5. Сдвиг вправо отрицательных значенийых. Для знаковых типов результат >> зависит от реализации: чаще всего это арифметический сдвиг (знаковый бит копируется в освободившиеся старшие позиции, число остаётся отрицательным), но стандарт гарантии не даёт. Поэтому >> для деления на 2 безопасен только для беззнаковых; для знаковых деление делают через обычный оператор /. Аналогия: арифметический сдвиг — как перетащить кубики вправо, не убирая знаковый кубик слева.

6. Обмен через XOR без временной переменной. Трюк a ^= b; b ^= a; a ^= b; действительно меняет значения местами, но он (а) не быстрее обычного обмена через временную переменную на современных процессорах (компилятор всё равно может вставить регистр), (б) хуже читается, (в) не работает, если a и b — один и тот же объект (a ^= a; a ^= a; a ^= a; обнулит значение, потому что x ^ x == 0). Поэтому на экзамене его уместно упомянуть как трюк, но в реальном коде предпочтительнее обычный обмен через tmp — он надёжнее и понятнее.

Экзаменационные тезисы (что нужно уметь отвечать).

• Побитовые операции: & (И), | (ИЛИ), ^ (XOR), ~ (NOT), << и >> (сдвиги).
• Для флагов используют беззнаковые типы, а маску бита k записывают как 1u << k.
• Установить бит: x |= mask; сбросить: x &= ~mask; проверить: (x >> k) & 1u или x & mask.
• Сдвиг влево эквивалентен умножению на 2^k, сдвиг вправо (для беззнаковых) — делению на 2^k.
• Сдвиг на величину ≥ ширины типа — UB; сдвиг знакового влево с переполнением — UB.
• Битовые &/| отличаются от логических &&/||: первые не short-circuit и работают с битами, вторые — short-circuit и возвращают 0 или 1.
• x & (x - 1) сбрасывает младший установленный бит — классический трюк для подсчёта единиц (алгоритм Брайана Кернигана).

printf и scanf: спецификаторы

Простыми словами. printf/scanf — это универсальные «принтер и сканер» значений, которые сами не знают типов ваших переменных. Поэтому вы вручную сообщаете функции, какие данные через неё проходят, специальными метками — спецификаторами формата. Спецификатор — это «пропуск» или «этикетка на посылке»: если он не совпадает с типом аргумента, функция прочитает или напечатает мусор, а компилятор чаще всего промолчит (потому что printf принимает переменное число аргументов через ... и не может проверить типы на этапе компиляции). Аналогия из жизни: в коробку положили число, а на ярлыке написали «строка» — получатель прочитает бессмыслицу и не узнает правды. На экзамене чаще всего ловят на несоответствии %d и size_t (нужен %zu), на пропущенном & в scanf (функция не может записать значение в переменную, если ей не передали адрес), а также на путанице %f (для printf это double) и %lf (для scanf это double, не float). Запомните триаду: спецификатор описывает тип аргумента, для scanf почти всегда нужен &, а для printf дополнительные флаги точности/ширины — это про визуальное форматирование, а не про тип. Почему это важно понимать глубже. Спецификатор — это не «украшение», а обязательство о размере и интерпретации битов: он говорит функции, сколько байт снять со стека и как их трактовать. Если вы передали int (4 байта), а написали %lld (8 байт), функция прочитает лишние 4 байта и напечатает чушь; если наоборот — потеряет старшие байты. Поэтому «работает на моей машине» здесь особенно опасно: код может печатать правильно на одной платформе и падать на другой. Ещё одна тонкость: %d и %i для printf ведут себя одинаково, но в scanf %i дополнительно понимает префиксы 0x (шестнадцатеричное) и 0 (восьмеричное) — это ловушка для ввода пользователя.

Аналогия из жизни. Представьте, что printf — это таможенник, а спецификатор — это декларация: «я везу коробку с 4 байтами». Если вы скажете «коробка с 8 байтами», а сами привезёте 4, таможенник всё равно возьмёт 8 — даже если придётся залезть в соседний грузовик. Результат непредсказуем. В Си это называется неопределённое поведение (UB): компилятор не обязан ничего проверять, ответственность — на программисте.

Почему компилятор не спасает. Стандарт C исторически разрешает вызывать вариативные функции (printf, scanf) без проверки типов аргументов — так работают эллипсисы .... Поэтому компилятор не может сверить спецификатор с реальным типом на этапе компиляции (точнее, не обязан). Современные компиляторы умеют предупреждать через -Wformat, но только для известных формат-строк; если строка собирается динамически (printf(msg)), предупреждения не будет. Вот почему аккуратность со спецификаторами — ваша личная ответственность, а не «забота IDE».

#include <stdio.h>

int main(void) {
    int    n = -42;
    unsigned u = 4000000000u;
    long   l = 9000000000L;             // суффикс L: значение не влезает в int
    double d = 3.14159;
    size_t s = sizeof n;                // size_t — правильный тип размеров

    printf("%d %i\n", n, n);            // %d и %i для вывода эквивалентны
    printf("%u %o %x %X\n", u, 255, 255, 255);   // беззнаковое, 8-, 16-ричное
    printf("%ld %zu %%\n", l, s);       // long, size_t, знак процента (%% = один %)
    // Ширина и точность: [%10.3f] — 10 позиций, 3 знака после точки
    // [%-10.3f] — выравнивание влево, [%+d] — всегда знак, [%05d] — нули слева
    printf("[%10.3f] [%-10.3f] [%+d] [%05d]\n", d, d, n, n);
    printf("%c %s %p\n", 'A', "текст", (void *)&n);   // %p требует void*
    return 0;
}

Мнемоника для запоминания суффиксов размера.

• %d — без суффикса → int. Буква d от слова decimal (десятичное).
• %ld / %lld — буква l как «long» → long / long long. Две буквы l подряд читайте как «long-long».
• %hd / %hhd — буква h как «half» → short / char. Две h подряд — «half-half», то есть вообще байт.
• %zu — буква z как «size» → size_t. Это согласовано с size_t в <stddef.h>.
• %Lf — столичная L как «Long double» (строчная l уже занята под long). Здесь легко ошибиться: %lf — это double, а %Lf — long double.

Подсказка-лайфхак для экзамена. Если забыли суффикс — посмотрите на сам тип: для int → %d, для long → %ld, для long long → %lld, для size_t → %zu, для double → %f (в printf) или %lf (в scanf). Связь «тип ↔ спецификатор» запоминается проще, чем каждый спецификатор по отдельности.

Типичные ошибки студентов (разбор).

1. printf("%d", sizeof x); — sizeof возвращает size_t (беззнаковый, на 64-бит 8 байт). Печатайте через %zu, иначе получите мусор или предупреждение -Wformat. Почему это работает кое-где: на 32-бит Linux size_t и unsigned int имеют одинаковый размер, и код случайно «совпадает». На 64-бит — расходятся, и вы видите -1, 4294967295 или обрезанные значения.
2. scanf("%f", &x); где x объявлен как double — для scanf оба типа (float и double) требуют своих спецификаторов: %f для float, %lf для double. В printf промежуточный %f подходит для double благодаря продвижению типа, а в scanf аргумент уже указатель — продвижения нет. Мнемоника: scanf принимает адрес «куда положить», printf — значение «что показать»; продвижение типа работает только для значений.
3. scanf("%d", n); без & — компилятор думает, что вы передаёте значение как int, а функция записывает по этому «адресу». Это почти всегда приводит к падению (UB). Исключение: char buf[N]; scanf("%s", buf); — массив сам «затухает» до указателя, & не нужен. Почему опасно: функция запишет прочитанное число по «адресу», который на самом деле является значением переменной — это почти гарантированный segfault или порча памяти.
4. printf("%s", ptr); где ptr — int * — компилятор выдаст предупреждение, %s ждёт char *. Явно приведите: printf("%s", (char *)ptr); либо используйте правильный тип с самого начала. Аналогия: функция ждёт ключ от квартиры, а вы даёте ключ от гаража — снаружи похоже, но внутрь не попасть.
5. Забытый %% для вывода знака процента — printf("100%") воспримет второй % как начало спецификатора и напечатает чушь либо проигнорирует. Совет: в строке формата каждый «настоящий» % обязан быть удвоен — это единственный случай «экранирования» в формат-строке.
6. printf("%s\n", str); где str не заканчивается на \0 — функция побежит по памяти до первого нулевого байта и напечатает мусор или упадёт. Строки в Си обязаны быть null-terminated; это контракт, а не пожелание.
7. printf("Число: %d\n", 3.14); — передаёте double, а пишете %d. Компилятор в лучшем случае выдаст предупреждение, в худшем — напечатает биты числа как целое (получите огромное число вроде 1374389535).

Как читать таблицу. Спецификатор — это не «украшение», а обязательство: тип аргумента должен совпадать с ним бит в бит, иначе поведение не определено (UB). Три правила, которые спасают на контрольной: для size_t берите %zu (самая частая ошибка — %d), для long long — %lld, а указатель печатайте через %p, приведя к void *. Ширина поля (%10.3f) влияет только на внешний вид и не меняет значение — это полезно для выравнивания таблиц в консоли.

Практический совет. Если компилятор поддерживает атрибут __attribute__((format(printf, ...))) (GCC/Clang), оборачивайте свои функции-обёртки вокруг printf — тогда компилятор будет проверять спецификаторы и в вашем коде. Это бесплатная страховка от ошибок формат-строки, которые иначе обнаруживаются только в рантайме.

Ширина, точность и флаги — шпаргалка.

• %10d — минимум 10 позиций, выравнивание вправо (по умолчанию для чисел). Если число короче — слева добавляются пробелы.
• %-10d — выравнивание влево. Полезно для таблиц: имя слева, число справа.
• %05d — дополнять нулями слева до 5 позиций. Удобно для дат, номеров заказов: 0042 вместо 42.
• %+d — всегда печатать знак (+ для положительных). Полезно в отчётах, где -5 и +5 должны быть видны оба.
• %.3f — три знака после точки. Округление, а не отбрасывание: 3.14159 → 3.142.
• %10.3f — общая ширина 10, из них 3 после точки. Точка входит в общую ширину, то есть 3.142 займёт 5 позиций, а остальное — пробелы.

Аналогия. Ширина — это «ширина полки в шкафу». Значение кладётся на полку; если оно короче — остаётся пустота (пробелы); если длиннее — полка «раздвигается», число не обрезается. Флаг 0 заполняет пустоту нулями (как пробирки, заполненные жидкостью), флаг - сдвигает значение влево (как книги с корешком слева).

В scanf другое правило: double требует %lf, float — %f, а перед всеми переменными обязателен & (кроме массивов, которые сами «затухают» до указателя). scanf возвращает число успешно прочитанных полей, EOF — при конце ввода; результат проверять обязательно, иначе цикл может зациклиться на «мусорном» вводе. Ширину задают для защиты буфера: scanf("%31s", buf), потому что без неё ввод длиннее буфера переполнит память (классическая уязвимость). Ещё две ловушки: %s в scanf читает до первого пробельного символа (для строки с пробелами нужен fgets или %[^\n]), а %d без ширины на символе, не являющемся цифрой, оставит его во входном потоке и зациклит чтение. Поэтому надёжнее читать строку через fgets, а число разбирать через strtol — это даёт контроль над ошибками и не зависит от «поведения scanf».

Почему fgets + strtol лучше scanf. scanf исторически спроектирован для простых учебных задач, а не для продакшена: он не сообщает, какая позиция во вводе «сломалась», не различает «не число» и «конец ввода», плохо работает с интерактивным вводом и небезопасен по умолчанию. fgets сначала читает строку фиксированной длины (нет переполнения), затем strtol разбирает её с указанием позиции ошибки через второй аргумент. Этот паттерн — стандарт индустрии, его спрашивают на собеседованиях в Яндекс, VK и других компаниях.

Экзаменационные тезисы по теме.

• printf продвигает float к double, поэтому %f годится; scanf так не делает — отсюда %lf для double. Это любимый вопрос преподавателей: «почему в одном случае %f, а в другом — %lf?»
• %zu — единственный корректный способ напечатать size_t; %d на некоторых платформах даст предупреждение, а на других — тихий мусор.
• & обязателен в scanf для всех скаляров; для массивов (char s[N]) — не нужен, потому что имя массива само преобразуется в указатель.
• Возвращаемое значение scanf (%d/%f) — это число успешно прочитанных полей, а не введённое значение. Всегда проверяйте if (scanf(...) != 1).
• Ширина в printf — только форматирование, она не обрезает значение. Ширина в scanf — это максимальное число символов, и она обрезает чтение, защищая буфер.
• %% — единственный способ вывести знак процента; нельзя писать \%, это не Pascal и не Python.
• %p требует именно void *; на практике компилятор часто принимает любой указатель и выводит, но формально это UB без приведения.

Пример безопасного ввода:

#include <stdio.h>
#include <stdlib.h>

int main(void) {
    char buf[32];
    if (!fgets(buf, sizeof buf, stdin)) return 1;   // fgets знает размер буфера
    char *end;
    long n = strtol(buf, &end, 10);                 // разбор числа с проверкой
    if (end == buf) {                               // ни одной цифры не прочитано
        fprintf(stderr, "не число\n");
        return 1;
    }
    printf("вы ввели %ld\n", n);
    return 0;
}

Указатели и адресная арифметика

Простыми словами. Указатель — это переменная, в которой лежит адрес памяти, а не само значение: как бумажка с адресом дома, а не сам дом. По бумажке можно дойти до дома и что-то с ним сделать, а можно потерять бумажку — и тогда дом есть, а вы о нём «забыли». Оператор & берёт адрес («узнать, где дом»), * идёт по адресу и достаёт значение («прийти по адресу и заглянуть внутрь»). Указатели — сердце Си: без них нет ни строк, ни динамической памяти, ни структур данных, поэтому этот вопрос спрашивают почти в каждом билете.

Зачем это вообще нужно. Без указателей функция не может изменить переменную вызывающего кода (параметры передаются по значению — копии). Без указателей нельзя работать с массивами переменной длины, динамической памятью (malloc), строками (char *) и структурами данных (связные списки, деревья). По сути, всё, что делает Си мощным — функции вроде scanf, free, обработчики сигналов — построено на указателях.

Указатель — переменная, хранящая адрес объекта. Тип указателя важен: он говорит, объект какого типа лежит по адресу, и задаёт шаг адресной арифметики. Операции: & (взять адрес), * (разыменовать), сложение с целым, вычитание и сравнение.

Аналогия для типа указателя. Если int *p — это «адрес дома, в каждой комнате живёт int», то char *p — «адрес дома, где в каждой комнате живёт char». Шаг между комнатами разный, поэтому +1 означает разное расстояние. Это помогает запомнить: тип указателя — это не про адрес, а про интерпретацию того, что по нему лежит.

Почему тип указателя влияет на арифметику. Процессор работает с байтами, а программист — с «элементами». Когда вы пишете int *p; p + 1;, компилятор переводит это в «сдвинуться на sizeof(int) байт», а не на 1 байт. Поэтому int * и char * при одинаковом +1 уйдут на разные расстояния. Это сделано специально, чтобы p[i] работало для любого типа без умножения на sizeof вручную. Именно этот вопрос «куда сдвинется указатель?» любят задавать на собеседованиях и экзаменах.

Почему нельзя складывать два указателя. Сложение указателей не имеет смысла: что значит «адрес дома №3 + адрес дома №5»? Это как складывать номера телефонов — результат не имеет интерпретации. Поэтому стандарт Си запрещает p1 + p2 — компилятор выдаст ошибку. Зато вычитание разрешено и даёт количество элементов между указателями (тип результата — ptrdiff_t).

#include <stdio.h>
#include <stddef.h>   // ptrdiff_t для разности указателей

int main(void) {
    int a[5] = {10, 20, 30, 40, 50};
    // Имя массива затухает до указателя на a[0]; p указывает на первый элемент
    int *p = a;
    // p + 2 сдвигает адрес не на 2 байта, а на 2 * sizeof(int) = 8 байт
    printf("%d %d\n", *p, *(p + 2));         // 10 30
    // Разность указателей даёт число ЭЛЕМЕНТОВ, а не байтов: %td для ptrdiff_t
    printf("%td %zu\n", (a + 4) - a, sizeof(int));   // 4 4
    p += 3;                                  // теперь p указывает на a[3]
    printf("%d\n", *p);                      // 40
    printf("%d\n", p[-1]);                   // 30 — p[-1] это сокращение для *(p - 1)
    return 0;
}

Аналогия из жизни. Указатель на int — это «адрес квартиры с указанием, что в ней живёт семья из 4 человек». Указатель на char — «адрес комнаты с указанием, что в ней один человек». Пройти +1 для первого — значит перейти к следующей квартире (4 байта), для второго — к следующей комнате (1 байт). Поэтому никогда не прибавляйте к указателю «байты» — только элементы.

Простыми словами. Указатель в Си — это переменная особого типа, которая хранит не само значение, а адрес другой переменной в оперативной памяти. С точки зрения памяти сам указатель занимает фиксированное число байт (4 на 32-битной платформе, 8 на 64-битной), но благодаря типизации компилятор знает, сколько байт занимает значение, на которое указатель ссылается — и это важно для адресной арифметики. Если int *p означает «адрес целого числа», то p + 1 сдвигается сразу на sizeof(int) байт, а не на 1. Именно поэтому int *p и char *c — разные типы, даже если оба указателя умещаются в одинаковое число байт: у них разная «цена деления».

• Арифметика идёт в единицах типа: p + 1 сдвигает адрес на sizeof(*p) байт. Именно поэтому int *p и char *c при одинаковом +1 уйдут на разные расстояния — это первое, что проверяют вопросом «куда сдвинется указатель?». Это нужно, чтобы адресная арифметика оставалась «осмысленной»: перебирая элементы массива int, мы должны попадать ровно в начало следующего int, а не в середину предыдущего.
• Вычитание указателей даёт число элементов (ptrdiff_t); сложение двух указателей запрещено, потому что сумма адресов не имеет смысла (компилятор выдаст ошибку). Тип результата ptrdiff_t — знаковый, специально предназначенный для разности двух адресов, поэтому он может быть отрицательным (когда правый указатель «левее»).
• Сравнивать и вычитать указатели допустимо только внутри одного массива: формально сравнивать адреса из разных объектов — UB, хотя на практике «работает» на большинстве платформ. Стандарт разрешает сравнивать указатели только в пределах одного объекта (включая «один за последним»), потому что в общем случае адреса разных объектов могут иметь произвольное взаимное расположение (особенно в сегментных моделях памяти).
• const читайте справа налево: const int *p — нельзя менять *p (указатель на константу); int * const p — нельзя менять p (константный указатель); const int * const p — нельзя ни то, ни другое. Мнемоника: «const прилипает к тому, что стоит слева от него», а пробежать назад по строке проще, чем разбираться в звёздочках. Практический совет: всегда начинайте чтение типа с имени переменной и идите наружу — это самый надёжный способ не запутаться в сложных объявлениях вроде const int * const *p.
• Указатель void * нельзя разыменовать и к нему нельзя прибавить число: сначала приводят к конкретному типу. Это «универсальная бумажка без указания, что внутри». Исторически void * появился как способ обойти систему типов: в Си он неявно приводится к любому указательному типу и обратно, что делает его удобным для обобщённых интерфейсов (malloc, memcpy, qsort). Но именно из-за отсутствия информации о размере элемента компилятор запрещает арифметику и разыменование до явного приведения.
• Разыменование NULL, «диких» (неинициализированных) и висячих указателей — UB; после free обнуляйте указатель. NULL в современном C — это ((void *)0), поэтому if (p) корректно проверяет «указатель не пуст». UB — это «неопределённое поведение» (undefined behavior): стандарт не определяет, что произойдёт, и теоретически компилятор может сгенерировать что угодно — от чтения мусора до падения, форматирования диска или вообще ничего. Это худший класс ошибок в Си, потому что программа может «работать» годами, а потом упасть в самый неподходящий момент.

Экзаменационные тезисы по теме.

• int *p, q; — здесь p указатель, а q обычный int. Звёздочка относится к переменной, а не к типу. Чтобы обе были указателями — int *p, *q;. Это любимый «подвох» преподавателей, и причина его существования — в грамматике Си: декларатор *p относится к p, а не ко всему списку имён через запятую.
• a[i] и *(a + i) — это одно и то же. Поэтому 2[a] тоже валидный Си (хотя так писать не надо), потому что сводится к *(2 + a). Это работает благодаря коммутативности сложения: оператор [] в стандарте определён именно как разыменование суммы индекса и указателя, поэтому порядок слагаемых не важен.
• sizeof(*p) даёт размер типа, на который указывает p, а не размер самого указателя (sizeof(p) всегда даёт размер адреса — 4 или 8 байт). Это часто путают: студенты думают, что sizeof(*p) зависит от платформы, но он зависит только от типа, на который указывает p.
• void * совместим с любым указателем без явного приведения в C (но не в C++); обратное приведение к конкретному типу обязательно перед использованием. Это одна из ключевых «несовместимостей» Си и C++: в C++ void * требует явного приведения, и код типа int *p = malloc(...) в C++ не скомпилируется без static_cast или (int *).
• Адресная арифметика вне массива (включая «один за последним элементом») — UB, кроме случая &arr[N] для расчёта конца. Это сделано для того, чтобы компилятор мог оптимизировать код, предполагая, что указатели всегда указывают внутрь одного объекта (или ровно на позицию «один за концом»). Практический вывод: не пишите циклы вида for (p = a; p < a + n; p++) с указателями из разных массивов и не передавайте указатели из разных массивов в одни и те же операторы сравнения.

Типичные ошибки студентов (разбор).

1. int *p; *p = 5; — указатель не инициализирован, *p пишет в случайную память. Всегда инициализируйте: int *p = &x; или хотя бы int *p = NULL;. На практике такая ошибка проявляется не сразу: программа может какое-то время работать, потому что в «мусорной» памяти оказывается что-то осмысленное, а затем неожиданно падать. Полезная привычка — включать предупреждения компилятора (-Wall -Wextra), которые ловят использование неинициализированных переменных.
2. scanf("%d", p); вместо scanf("%d", &x); — здесь как раз тот случай, где p уже указатель, и &p взял бы адрес самого указателя. Проверяйте уровень косвенности. Правило большого пальца: если scanf требует указатель на переменную, а у вас уже есть указатель — & не нужен; если есть обычная переменная — & нужен. Для строк (%s) & тоже не нужен, потому что имя массива само «затухает» в указатель.
3. p = p + 1; для void * — компилятор выдаст ошибку: void * не имеет размера. Сначала приведите к типу. Причина та же: компилятор не знает, на сколько байт сдвигать, потому что void означает «ничего конкретного». Решение — привести тип: char *cp = (char *)p; cp++; или сразу работать с типизированным указателем.
4. Сравнение указателей из разных массивов (if (p1 < p2)) — формально UB, даже если адреса выглядят «разумно». Стандарт разрешает сравнивать только внутри одного объекта. На практике в плоской модели памяти (все современные ОС) адреса разных объектов всё равно корректно сравниваются по числовому значению, но компилятор вправе использовать допущение стандарта для агрессивных оптимизаций. Не полагайтесь на это — пишите код, который корректен по стандарту.
5. Забытый free или, наоборот, двойной free — после освобождения памяти обнуляйте указатель (p = NULL;), иначе free(p); free(p); — двойное освобождение и UB. Это худший класс ошибок работы с памятью: утечки памяти (memory leak) просто «съедают» RAM, а двойное освобождение может повредить кучу (heap) и привести к падению в произвольном месте программы. Современные инструменты (AddressSanitizer, Valgrind) ловят обе проблемы автоматически — обязательно используйте их при отладке.

Массивы и указатели (decay)

Простыми словами. Массив — это непрерывный блок ячеек одного типа, а имя массива в выражении превращается («затухает», decay) в указатель на первую ячейку. Аналогия: массив — дом с пронумерованными квартирами; при затухании вы передаёте в функцию только адрес первой квартиры, и функция больше не знает, сколько квартир в доме. Именно поэтому длину массива почти всегда передают отдельным параметром — это самая частая причина ошибок у первокурсников. Идея decay — в эффективности: копировать весь массив в функцию дорого, поэтому в Си исторически решили передавать только адрес первого элемента, а длину сообщать отдельным параметром. Это требует дисциплины от программиста, но даёт максимальную скорость.

Имя массива в выражении затухает (decay) до указателя на первый элемент. Исключения: sizeof, &arr, _Alignof и инициализация строковым литералом. Эти исключения нужны, чтобы можно было узнать размер массива и его адрес как «объекта в целом» (а не как адрес первого элемента).

#include <stdio.h>

// int a[] в параметре — тот же int *a: размер массива здесь узнать нельзя,
// поэтому длину передают вторым параметром (int n)
void f(int a[]) {
    printf("в функции: %zu (это размер указателя, а не массива)\n", sizeof a);
}

int main(void) {
    int arr[10];
    // sizeof arr даёт размер ВСЕГО массива: 10 * 4 = 40 байт;
    // sizeof arr / sizeof arr[0] = число элементов — работает только здесь,
    // где arr действительно массив, а не указатель
    printf("массив: %zu элементов: %zu\n",
           sizeof arr, sizeof arr / sizeof arr[0]);  // 40, 10
    // &arr имеет тип «указатель на массив из 10 int» — это тоже 8 байт адреса,
    // но арифметика по нему идёт шагом в весь массив
    printf("&arr: %zu\n", sizeof &arr);              // 8 — указатель на массив
    f(arr);                                          // передаём адрес первого элемента
    return 0;
}

Из-за decay функцию нельзя спросить о длине массива — её передают отдельным параметром. sizeof arr / sizeof arr[0] работает только там, где arr — настоящий массив. Запомните три исключения, где массив не затухает: sizeof arr, &arr и _Alignof(arr). Ещё одно следствие decay: указатель и массив в выражении почти взаимозаменяемы, поэтому a[i] компилятор превращает в *(a + i) — отсюда и странная, но законная запись 2[a], которая тоже означает *(2 + a). На экзамене это отличный вопрос-ловушка: «почему i[a] эквивалентно a[i]?» — потому что + коммутативна, а [] определён именно через разыменование суммы. Практический совет: если вам в функции нужна длина массива, есть три варианта: (1) передавать её отдельным параметром, (2) использовать «sentinel-значение» (например, '\0' в строках), (3) использовать C99 VLA с осторожностью (но в современном C VLA признан неудачным и опциональным). Самый надёжный путь — первый.

Многомерные массивы

Простыми словами. Двумерный массив — это массив массивов: int a[3][4] читается как «три элемента, каждый — массив из четырёх int». В памяти он лежит одним непрерывным блоком по строкам (row-major): сначала все четыре числа первой строки, потом второй и так далее. Аналогия: это тетрадь в клетку — вы заполняете первую строку слева направо, только потом переходите ко второй. Отсюда формула a[i][j] == *(*(a + i) + j), которую любят просить вывести на экзамене. Важно понимать разницу с языками вроде Фортрана или MATLAB: там порядок column-major (сначала заполняется столбец), и эта разница иногда всплывает при численных расчётах — в Си доступ к элементам одной строки заметно быстрее, чем к элементам одного столбца (из-за кеш-памяти процессора).

int a[3][4] — массив из трёх массивов по четыре int; в памяти он непрерывен и хранится по строкам (row-major). Формула: a[i][j] == *(*(a + i) + j).

#include <stdio.h>

void print(int a[][4], int rows) {       // вторая размерность обязательна: без неё нет шага строки
    for (int i = 0; i < rows; i++) {
        for (int j = 0; j < 4; j++) printf("%d ", a[i][j]);
        putchar('\n');
    }
}

int main(void) {
    // Вложенные списки инициализаторов: 3 строки по 4 элемента
    int m[3][4] = {{1, 2, 3, 4}, {5, 6, 7, 8}, {9, 10, 11, 12}};
    print(m, 3);
    // m[0] — это массив из 4 int: одна «строка» занимает 16 байт;
    // весь массив m — 48 байт, то есть 3 строки по 16
    printf("sizeof строки: %zu, всего: %zu\n", sizeof m[0], sizeof m);
    return 0;
}

При передаче int a[][4] эквивалентно int (*a)[4] — указателю на массив из 4 int. Вторая размерность обязательна, потому что именно она задаёт шаг, на который указатель сдвигается при переходе к следующей строке; первую размерность писать можно, но она всё равно теряется. Типичная ошибка — объявить параметр как int ** и передать в него m: это разные типы, и программа упадёт или прочитает мусор. Динамический двумерный массив строят двумя способами: как массив указателей (int **, каждая строка выделена отдельно — удобно для треугольных матриц, но медленнее) или как один непрерывный блок rows * cols с ручной индексацией i * cols + j (быстрее и кеше-дружелюбнее — то, что ждут на экзамене). Сравнение подходов: int ** проще для треугольных/нерегулярных структур (каждая строка может иметь свой размер), а плоский блок с индексацией — быстрее из-за последовательного доступа в памяти. Мнемоника для запоминания: «вторая размерность — это размер строки в int, она должна быть известна компилятору, чтобы он мог пересчитать a[i][j] в адрес; первая размерность — это число строк, оно переменное и передаётся параметром».

Разбор типовой ошибки. int **p = (int **)m; — так делать нельзя: m после decay имеет тип int (*)[4], а не int **. Компилятор выдаст предупреждение о несовместимых указателях, а если привести тип молча — p[1] прочитает не адрес строки, а число из первой строки и «разыменует» его. Правильный путь — либо честный int (*p)[4], либо явное построение массива указателей. Чтобы понять, почему так происходит: представьте, что int (*)[4] — это указатель на «коробку» размером 16 байт (строку), а int ** — это указатель на указатель (8 байт на 64-бит). Когда вы делаете p[1], компилятор прибавляет к p размер int * (8 байт), а должен был бы прибавить 16 байт (размер всей строки). В итоге он попадает в середину первой строки и читает «мусор» как указатель — это и есть причина падения.

Строки в C

Простыми словами. Строка в Си — это массив символов, в конце которого стоит нулевой байт '\0'. Длина нигде не хранится: любая строковая функция идёт по байтам, пока не встретит этот ноль. Аналогия: '\0' — точка в конце предложения; если точку забыть, читатель не поймёт, где кончается текст, и побежит читать дальше по чужим страницам (это и есть выход за границы буфера). На экзамене это самая частая тема контрольных «без библиотечных функций». Альтернативный способ организации строк — хранить длину отдельно (как в C++ std::string или Pascal): он безопаснее, но в Си исторически выбрали вариант с '\0' ради совместимости с указателями и экономии памяти. Практический вывод: всегда используйте функции с явным ограничением длины (strncpy, snprintf, fgets), а не их «неограниченные» версии (strcpy, sprintf, gets).

Строка — массив char, завершающийся нулевым байтом '\0'. Длина не хранится: функции ищут '\0', поэтому забытый терминатор ведёт к чтению за границей.

#include <stdio.h>
#include <string.h>

int main(void) {
    // s1 — ИЗМЕНЯЕМАЯ копия литерала в локальном массиве;
    // sizeof(s1) включает '\0'. В UTF-8 каждая русская буква — 2 байта,
    // поэтому strlen вернёт число БАЙТ, а не число букв
    char s1[] = "мир";
    // s2 — только указатель на литерал, лежащий в памяти только для чтения
    char *s2 = "мир";

    printf("len=%zu sizeof=%zu lit=%zu\n",
           strlen(s1), sizeof s1, strlen(s2));   // 6 7 6 в UTF-8
    // Меняем ЛАТИНСКИЙ буфер: один байт = один символ, всё предсказуемо.
    // Для строки "мир" побайтовая правка сломала бы UTF-8 (буква = 2 байта)
    char ascii[] = "abc";
    ascii[0] = 'A';           // OK: меняем свою копию
    puts(ascii);              // Abc
    // s2[0] = 'X';           // UB: литерал изменять нельзя

    // snprintf гарантирует, что запись не выйдет за sizeof buf
    char buf[64] = "";        // пустая строка: первый байт уже '\0'
    snprintf(buf, sizeof buf, "%s + %s", "Си", "строки");
    puts(buf);
    return 0;
}

Строка в Си — это просто массив байтов, заканчивающийся нулём '\0'. Никакого отдельного «строкового» типа в языке нет: компилятор и стандартная библиотека договорились о соглашении — последний байт равен нулю, всё, что до него, — полезные символы. Из-за этого соглашения возникает большинство ошибок: забытый терминатор, нехватка места в буфере, неверный размер. Поэтому функции <string.h> нужно знать наизусть — какие гарантии они дают, а каких не дают. Полезная аналогия: строка в Си — это вагон с грузом, у которого последний вагон всегда пустой (вагон-терминатор); если вы забыли прицепить пустой вагон, поезд будет ехать, пока не встретит «случайный пустой вагон» в составе — то есть пока не прочитает мусор из чужой памяти.

Запомните: strlen возвращает size_t без терминатора; strcpy/strcat не проверяют размер; strcmp возвращает 0 при равенстве; strncpy может не поставить '\0'. Безопасные замены — snprintf, fgets, strncat с явным контролем.

Разница между строкой и массивом символов — важный устный вопрос, и студенты на нём проваливаются чаще всего. Массив символов — это просто хранилище байтов: они лежат в памяти подряд, индексируются с 0, и компилятор ничего о «строковости» не знает. Если последний байт не равен '\0', это не строка, а буфер — и strlen, printf %s, strcpy будут читать дальше, пока не встретят ноль где-то в чужой памяти. Строка — это массив, гарантированно завершённый '\0', поэтому с ней безопасно работают строковые функции. Аналогия: массив символов — это блокнот с буквами, в котором может не быть точки в конце предложения; строка — это блокнот, где последний символ обязательно точка, и «читатель» останавливается на ней. Ещё одно отличие — про размер. sizeof отвечает на вопрос «сколько байт компилятор отвёл под буфер?» и известен на этапе компиляции. strlen отвечает на вопрос «где сейчас находится терминатор?» — это число вычисляется во время выполнения проходом по массиву. Для строкового литерала "abc" эти величины различаются на единицу: sizeof("abc") = 4 (три буквы + терминатор), strlen("abc") = 3 (только буквы). Эту пару обожают и на собеседованиях, и на устных экзаменах — ответ «обе дают длину строки» сразу выдаёт непонимание модели памяти Си.

Функции: передача по значению и по указателю

Простыми словами. Аргумент — это значение, которое функция получает при вызове. В Си действует единственный механизм: передача по значению (pass-by-value), то есть функция работает с копией, а не с оригиналом. Аналогия: вы снимаете ксерокопию с договора и правите её сколько угодно — оригинал в это время лежит в сейфе и не меняется. Чтобы функция всё-таки изменила переменную вызывающего, ей передают адрес этой переменной (указатель) — тогда она работает не с копией, а с самим «оригиналом» через указатель на него. Это первый вопрос к любой задаче «поменять местами / заполнить массив / вернуть два значения», так что формулировку «всё передаётся по значению, изменение — только через указатель» нужно помнить как аксиому. И даже передача «массива по указателю» — это на самом деле та же передача по значению: копируется указатель на первый элемент, а не сам массив.

В C все аргументы передаются по значению — функция получает копии. Чтобы изменить переменную вызывающего, передают указатель.

#include <stdio.h>

void swap_bad(int a, int b) { int t = a; a = b; b = t; }   // меняет КОПИИ — бесполезно
void swap(int *a, int *b)   { int t = *a; *a = *b; *b = t; } // меняет ОРИГИНАЛЫ через адреса

// Рекурсия: база n < 2 (иначе бесконечность), затем сведение к двум меньшим задачам
// Минус: fib(40) делает ~2^40 вызовов — экспоненциально медленно
int fib(int n) {
    if (n < 2) return n;
    return fib(n - 1) + fib(n - 2);
}

int main(void) {
    int x = 1, y = 2;
    swap_bad(x, y);                           // передали значения — x и y не изменились
    printf("%d %d\n", x, y);                  // 1 2
    swap(&x, &y);                             // передали адреса — функция пишет по ним
    printf("%d %d\n", x, y);                  // 2 1
    printf("fib(10) = %d\n", fib(10));        // 55
    return 0;
}

• Прототип функции — это её объявление без тела (void swap(int*, int*);). Он сообщает компилятору сигнатуру до определения, чтобы тот мог проверить типы аргументов при любом порядке функций в файле. Без прототипа старый компилятор (С89) молча примет любые аргументы — и баг найдётся только в рантайме, а не при сборке.
• Возвращать указатель на локальную переменную нельзя — это классический висячий указатель (dangling pointer): память кадра освобождается сразу после return, а указатель остаётся «в никуда». Пример-ошибка: int* f() { int x = 1; return &x; } — &x указывает на уже мёртвую память, и чтение *p снаружи — UB. Если локальная переменная нужна «снаружи», её выносят в static (живёт до конца программы), в кучу (malloc, освобождать через free) или передают указатель на неё извне.
• Рекурсия требует двух вещей: базы (условия остановки, иначе бесконечность) и сходящегося шага (параметр приближается к базе с каждым вызовом). Классический вопрос билета: «какие две вещи обязательны для рекурсии?» — ответ: база и приближение к ней. Если забыть любое из них, программа либо зациклится, либо получит переполнение стека.
• Глубокая рекурсия переполняет стек (типично ~10⁴–10⁵ кадров на процесс; зависит от ОС и размера кадра). Поэтому fib(40) наивной реализации даёт ~2³⁹ вызовов и считается секунды — здесь помогает либо мемоизация (сохранение уже посчитанных значений), либо прямой переход к циклу.
• Любая рекурсия переписывается циклом; хвостовую рекурсию (когда рекурсивный вызов — последняя операция в функции) оптимизатор может превратить в цикл, экономя стек. Рекурсия короче и выразительнее (деревья, обходы графов, разбор выражений, quicksort), но итерация экономит стек и обычно быстрее за счёт отсутствия накладных расходов на вызов.
• Мнемоника «рекурсия — матрёшка»: чтобы достать самую маленькую куклу, нужно открывать по одной и помнить, где вы сейчас; база — это последняя, неоткрываемая кукла; без неё матрёшка бесконечна, и стек «матрёшек» растёт до переполнения.
• Вернуть сразу несколько значений в Си «штатным» return нельзя — return один и возвращает одно значение. Поэтому применяют либо выходные параметры через указатели (void get(int *a, int *b)), либо структуру (struct Pair get(void)). Второй способ читается лучше и рекомендуется в современном C: имя поля само подсказывает, что где лежит, и нет соблазна передать NULL.

Указатели на функции

Простыми словами. Указатель на функцию — это переменная, в которой хранится адрес машинного кода функции. Через неё можно вызвать функцию, не зная заранее, какая именно это функция: сегодня это сложение, завтра — умножение. Аналогия: это «номер телефона» функции — номер можно положить в переменную и «позвонить» по нему, не зная заранее, кто именно ответит. На указателях на функции держатся qsort/bsearch с callback, таблицы переходов в интерпретаторах и state-машинах, обработчики событий в GUI и сетевом коде, поэтому вопрос про них встречается и в билетах, и в задачах на защиту. Главное, что нужно помнить: тип указателя включает в себя сигнатуру функции (типы и число аргументов + тип возврата) — иначе вызов через указатель другого типа даёт UB.

#include <stdio.h>
#include <stdlib.h>

int add(int a, int b) { return a + b; }
int mul(int a, int b) { return a * b; }

int cmp(const void *a, const void *b) {       // сигнатура, которую ждёт qsort
    // qsort передаёт адреса элементов, поэтому приводим void* к int*
    int x = *(const int *)a, y = *(const int *)b;
    return (x > y) - (x < y);                 // -1/0/+1 без переполнения, в отличие от x - y
}

int main(void) {
    // Объявление указателя на функцию: op — указатель на функцию int(int, int).
    // Скобки вокруг *op обязательны: int *op(int,int) — это функция, возвращающая int*
    int (*op)(int, int) = add;
    printf("%d\n", op(3, 4));                 // 7 — вызов через указатель
    op = mul;                                 // переключили поведение
    printf("%d\n", op(3, 4));                 // 12

    int arr[] = {5, 1, 4, 2, 3};
    qsort(arr, 5, sizeof arr[0], cmp);        // передаём функцию как аргумент (callback)
    for (size_t i = 0; i < 5; i++) printf("%d ", arr[i]);
    putchar('\n');
    return 0;
}

Тип int (*)(int, int) читается так: «указатель на функцию, принимающую два int и возвращающую int». Скобки вокруг * обязательны: int *f(int, int) — это уже функция, возвращающая int*. Правило простое: видите имя в скобках рядом со звёздочкой — это указатель; скобок нет — функция. Этот же тип int (*)(int,int) можно использовать как параметр (void apply(int (*op)(int,int), int x, int y)), как поле структуры и как элемент массива. Массив указателей на функции — основа таблиц переходов, например калькулятора из раздела «Польская запись»: вместо длинного switch держат int (*ops[])(int,int) = {add, sub, mul, div}; и вызывают ops[i](a,b). Именно такое решение часто просят «улучшить» на защите: оно короче, легче расширяется новой операцией (просто добавить элемент в массив) и не зависит от цепочки if-else.

Типичная ошибка. Забыть скобки и написать int *op(int, int) вместо int (*op)(int, int): компилятор объявит функцию, возвращающую указатель, а не переменную-указатель, и код либо не соберётся, либо соберётся не то, что задумано. Второй источник ошибок — вызов: (*op)(a,b) и op(a,b) оба корректны и полностью равнозначны (указатель на функцию автоматически разыменовывается, как и (*p).x vs p->x), но op(a,b) читается проще, и на экзамене лучше выбирать именно его. Третья частая ошибка — лишний & при передаче функции в qsort или собственную функцию высшего порядка: qsort(arr, n, sz, cmp) правильно, а qsort(arr, n, sz, &cmp) скомпилируется из-за автопреобразования функция→указатель, но писать & для функций не нужно и считается дурным тоном (за исключением взятия адреса для хранения в массиве указателей, где это тоже необязательно).

Структуры, объединения, битовые поля, typedef, enum

Простыми словами. Это четыре разных «способа группировки данных» в Си, и у каждого своя область применения. Разберём на одной аналогии — «карточка на полке»:

• struct — анкета из нескольких именованных полей разного типа: как карточка студента (имя, курс, средний балл, группа) — все поля лежат в памяти рядом, друг за другом, и обращаться к ним можно по имени. Размер struct — это сумма размеров полей (плюс возможное выравнивание).
• union — стакан, в который в разное время наливают либо воду, либо сок, либо чай: один и тот же участок памяти интерпретируется как один из нескольких типов. Размер union — это размер самого большого поля, а не сумма. Экономит память, но требует от программиста помнить, что именно сейчас лежит в union, — иначе это UB.
• Битовые поля — микро-ячейки внутри unsigned int, где каждому полю выделено ровно заданное число бит (1, 3, 4…). Удобно для упаковки флагов и регистров периферии (например, статусы устройств в ядре ОС).
• enum — набор именованных целочисленных констант вместо «магических чисел» в коде (COLOR_RED вместо 0, COLOR_GREEN вместо 1). Компилятор сам присваивает значения по порядку, но любой элемент можно задать явно.

Эти четыре конструкции нужны и в структурах данных (узел списка, вершина дерева, запись таблицы), и в системном коде (флаги регистров, дескрипторы ОС), поэтому спрашивают их постоянно. Если ответ на устном вопросе «чем отличается struct от union» звучит как «обе группируют данные» — это уже плохо; правильный ответ: «struct хранит все поля одновременно и занимает сумму их размеров, а union хранит только одно из них, перекрывая остальные в одной памяти и занимая место по размеру самого большого поля».

#include <stdio.h>
#include <stddef.h>   // offsetof

typedef struct Point { int x; int y; } Point;      // typedef даёт короткое имя типа

struct Flags {                                     // битовые поля: упаковка в биты
    unsigned ready : 1;                            // 1 бит — флаг «готов»
    unsigned mode  : 3;                            // 3 бита — значение 0..7
    unsigned       : 4;                            // анонимный padding, до байта
};

union Value { int i; float f; unsigned char b[4]; };  // все поля делят одну память

enum Color { RED, GREEN = 5, BLUE };               // RED=0, GREEN=5, BLUE=6

int main(void) {
    Point p = {.y = 2, .x = 1};                    // designated initializers (C99): порядок не важен
    Point *pp = &p;                                // указатель на структуру
    // Доступ через -> это сокращение для (*pp).x; offsetof даёт смещение поля в байтах
    printf("(%d,%d) offset_y=%zu\n", pp->x, pp->y, offsetof(Point, y));

    struct Flags fl = {.ready = 1, .mode = 5};
    printf("%u %u sizeof=%zu\n", fl.ready, fl.mode, sizeof fl);

    union Value v;
    v.f = 1.0f;                                    // записали float...
    // ...и читаем те же 4 байта как int: это не преобразование, а переинтерпретация битов
    printf("union: %08x, размер %zu BLUE=%d\n", v.i, sizeof v, (int)BLUE);
    return 0;
}

Составные типы в Си: что это. struct, union и enum — три способа сгруппировать данные. struct — как заполненная анкета: каждое поле лежит в своём слоте. union — как карман, в котором в разное время хранится то монета, то ключ (положили новое — старое перезаписалось). enum — нумерованный список с человеко-читаемыми именами. Преподаватели МИФИ, МГУ и МФТИ любят эту тройку за простоту и большое количество подводных камней.

• struct хранит поля последовательно с выравниванием (padding), union — внахлёст: размер union равен размеру самого большого поля, потому что все поля начинаются с одного адреса. Аналогия: struct — это ящик стола с отделениями (каждое поле — отдельная ячейка); union — это одна ячейка, в которой сейчас лежит либо молоток, либо отвёртка. Поэтому читать «неактивное» поле union — частая причина ошибок: компилятор ничего не заметит, но семантика данных будет сломана.
• Выравнивание (padding) — это «пустые» байты между полями, чтобы каждое поле начиналось с адреса, кратного его размеру. Почему так: процессор за один такт читает из памяти машинное слово (обычно 4 или 8 байт); если int попадает «по кривой» адресу, нужно два обращения к шине — вдвое медленнее. Компилятор сам вставляет выравнивание, чтобы код был быстрее. Пример: struct { char c; int i; } занимает 8 байт, а не 5: после c компилятор вставил 3 байта выравнивания. Порядок полей по убыванию размера даёт минимум padding — это стандартный вопрос «как сэкономить память структуры». Полезный приём: с помощью _Alignof/alignof или offsetof можно увидеть, где стоят «дыры», и при необходимости переупорядочить поля. В сетевых протоколах и форматах файлов padding мешает — там либо вручную упаковывают, либо используют #pragma pack.
• Битовые поля экономят память, но их раскладка зависит от реализации, и адрес поля взять нельзя; переносимость таких структур между компиляторами не гарантирована. Что это: unsigned int flag : 1; означает «отвести под flag ровно один бит». Используют для экономии памяти, когда объектов очень много (миллионы флагов), или в драйверах устройств, где каждому регистру отводится своё битовое поле. Почему осторожно: стандарт Си не фиксирует, с какой стороны биты растут и где начинается следующее поле — это решает реализация. Поэтому битовые поля нельзя использовать в сетевых протоколах и форматах файлов без #pragma pack или явной спецификации, иначе код поедет на другой платформе. Также нельзя взять адрес битового поля (&f.flag) — формально запрещено стандартом.
• enum — целочисленные именованные константы, удобны в switch: компилятор предупредит, если вы забыли обработать какое-то значение. По умолчанию нумерация начинается с нуля и увеличивается на единицу, но можно задать значения явно (GREEN = 5). Аналогия: вместо «магических» чисел 0/1/2/3 вы пишете осмысленные названия — код становится понятным, а компилятор помогает найти забытые ветки. В Си (в отличие от C++) enum — это просто int; размер не фиксирован, а базовый тип определяется реализацией. Если нужен строго 32-битный тип — берут uint32_t из <stdint.h>.
• typedef не создаёт новый тип, а лишь даёт синоним: typedef struct Point Point; избавляет от необходимости писать слово struct в каждом объявлении. Это стилистическое, но важное улучшение читаемости, которое ждут в курсовой. Почему в Си это проблема: структуры и обычные имена живут в разных «пространствах имён» — нельзя написать Point p;, нужно struct Point p;. typedef снимает эту неловкость: typedef struct { int x, y; } Point; — и дальше Point работает как обычный тип. Распространённая ошибка студентов — спрятать структуру через typedef и потерять прозрачность; в учебных проектах преподаватели часто просят, чтобы тег и typedef-имя различались (например, struct Point_ + typedef struct Point_ Point;).
• union + enum = «размеченное объединение» (tagged union): поле-тег хранит, какой вариант сейчас активен. Так реализуют, например, тип «значение» — либо int, либо double, либо строка. Простыми словами: это «коробка с ярлыком». Без enum-тега вы не знаете, что внутри, и рискуете прочитать биты int как double — типичная ошибка, выглядящая как «странный» вывод программы. В Rust/Haskell подобная конструкция встроена в язык (enum со связанными данными); в Си её собирают вручную — за это и любят давать на экзамене. На собеседованиях просят написать простой tagged union для «узла AST» или «варианта ответа сервера».

Динамическая память

Простыми словами. Куча — это «склад» памяти, которым программа распоряжается вручную: malloc — «арендовать ячейку нужного размера», free — «вернуть ключ от ячейки». Куча нужна, когда размер данных неизвестен заранее или объект должен жить дольше функции. Аналогия: стек — это полка у рабочего стола, которая сама убирается при выходе из функции; куча — арендованный склад, который надо освобождать самому, иначе он забьётся (утечка памяти). На экзамене почти всегда просят написать функции без утечек — это проверка аккуратности.

Когда без кучи не обойтись. Размер становится известен только в рантайме (например, прочитали n из файла), объект должен пережить функцию (возвращаем int* из фабрики), нужен массив, растущий по мере добавления элементов. В остальных случаях хватает автоматической памяти стека — она быстрее и не требует free. Хорошее правило: если можно обойтись VLA или массивом фиксированного размера — обходитесь без кучи.

Четыре функции: malloc, calloc, realloc, free. Запомните их как «MCRF»: M-выделить, C-выделить-с-нулями, R-перевыделить, F-освободить.

#include <stdio.h>
#include <stdlib.h>

int main(void) {
    size_t n = 5;
    // malloc выделяет n * sizeof(int) байт; записи sizeof *a достаточно,
    // и при смене типа a выражение менять не придётся — это идиома C
    int *a = malloc(n * sizeof *a);
    if (!a) { perror("malloc"); return 1; }       // проверять результат ВСЕГДА

    int *z = calloc(n, sizeof *z);                // calloc обнуляет память
    if (!z) { free(a); return 1; }                // не забываем освободить уже выделенное

    // realloc может переехать в другое место и вернуть новый адрес.
    // НЕЛЬЗЯ писать a = realloc(a, ...): при неудаче потеряется старый указатель
    int *tmp = realloc(a, 10 * sizeof *a);
    if (!tmp) { free(z); free(a); return 1; }     // при неудаче a по-прежнему действителен
    a = tmp;

    for (size_t i = 0; i < 10; i++) a[i] = (int)i;
    printf("%d %d\n", a[9], z[0]);                // 9 0 (calloc обнулил)

    free(z);
    free(a);
    a = NULL;                                     // защита от double free
    return 0;
}

Разбор кода по строкам. Здесь собраны сразу три ситуации — успех, частичный успех и обработка ошибок. Обратите внимание на три вещи:

1. sizeof *a вместо sizeof(int) — идиома «устойчивости к смене типа»: если завтра a станет double*, не придётся править формулу. Это любимый приём преподавателей и ревьюеров.
2. Проверка каждого возвращаемого указателя на NULL. В учебных проектах можно опустить, в продакшн-коде — обязательно. Альтернатива — exit(EXIT_FAILURE) вместо return 1.
3. При ошибке realloc мы освобождаем уже выделенное (a остался валидным), а затем — z. Это пример «симметрии аллокаций»: сколько выделили — столько же освободили, даже если поймали ошибку на полпути.

Таблица функций. Запомните минимум: что выделяет, инициализирует ли, что делает при ошибке.

Типичные ошибки: утечка (нет free), use-after-free, двойное освобождение, потеря указателя при realloc, обращение за границей, чтение неинициализированных данных. Подробнее по каждой:

• Утечка памяти — выделили malloc, но забыли free или потеряли указатель. Программа работает, но процесс «ест» память. Ловится valgrind --leak-check=full ./prog или -fsanitize=address.
• Use-after-free — обратились к памяти после free. Может вернуть вроде бы правильные данные (память ещё не занята), а может — мусор или SIGSEGV.
• Двойной free — free(p) дважды, обычно когда два указателя указывают на один блок. Защита — после free сразу p = NULL; (повторный free(NULL) безопасен).
• Потеря при realloc — a = realloc(a, ...) без временной переменной. При неудаче realloc вернёт NULL, и старая память «потеряется» вместе с исходным указателем. Решение — int *t = realloc(a, n); if (!t) { /* старый a валиден */ } else a = t;.
• Обращение за границей — a[i] при i >= n. C не проверяет границы автоматически; ищите через санитайзеры.
• Чтение неинициализированных данных — malloc не зануляет, поэтому int *a = malloc(...); a[0]++; — это чтение мусора. Лечится calloc или memset(a, 0, n*sizeof *a).

Как объяснить таблицу на экзамене. malloc и calloc отличаются только инициализацией: calloc обнуляет и удобен, когда нужен «чистый» массив; malloc быстрее (не тратит время на зануление), но данные в нём мусорные. realloc — единственная функция, которая может переместить блок: если после него нет свободного места, он выделит новый участок, скопирует данные и освободит старый, вернув новый адрес. Отсюда правило: сохраняйте результат во временную переменную и присваивайте исходной только после проверки на NULL. free(NULL) безопасен по стандарту, а вот free указателя, полученного не из malloc/calloc/realloc, или повторный free — UB.

Мини-история про realloc. Представьте, что вы арендовали склад (malloc). Приехало больше товара — вы просите realloc «сделай склад больше». Менеджер смотрит: позади соседний склад свободен? Если да — достраивает на месте. Если нет — находит новое большое здание, перевозит товар, сдаёт старый склад и возвращает вам ключ от нового. Ключевой момент: если переезд не удался (например, нет большого здания), менеджер не трогает ваш старый склад и возвращает пустой ключ — поэтому временная переменная критична.

Проверка себя: сколько free должно быть на каждое «выделение»? Правило симметрии «сколько malloc — столько free» (с поправкой на realloc и передачи владения в другую функцию) — это то, что проверяют утечки через Valgrind и AddressSanitizer. На экзамене назовите флаг -fsanitize=address — это покажет, что вы знакомы с практикой, а не только с теорией. Практический совет: запустите свою курсовую с -fsanitize=address -g — он покажет каждое UB и утечку с точностью до строки. Это быстрее, чем valgrind, и работает без отдельной установки.

Файлы: текстовые и бинарные

Простыми словами. Работа с файлом идёт через «поток» FILE * — это канал между программой и файлом на диске. Аналогия: fopen — открыть кран, fclose — закрыть его; пока кран не закрыт, часть воды (данных) остаётся в шланге-буфере и может не дойти до диска. Поэтому забытый fclose — это не только утечка дескриптора, но и потеря последних записанных строк. На экзамене это классическая задача на курсовой: «сохранить и прочитать структуру из файла».

Работа идёт через FILE *. Поток буферизуется, поэтому fclose (или fflush) обязателен — иначе данные не попадут на диск. Под буферизацией понимается, что fprintf пишет не на диск напрямую, а в область памяти stdio («буфер»); при fclose/fflush буфер выталкивается на диск одним системным вызовом.

#include <stdio.h>

int main(void) {
    // Текстовый режим
    FILE *out = fopen("out.txt", "w");            // "w" создаёт/обрезает
    if (!out) { perror("fopen"); return 1; }
    fprintf(out, "строка %d\n", 1);
    fclose(out);

    FILE *in = fopen("out.txt", "r");
    if (!in) return 1;
    char line[128];
    while (fgets(line, sizeof line, in)) fputs(line, stdout);
    if (ferror(in)) fprintf(stderr, "ошибка чтения\n");
    fclose(in);

    // Бинарный режим
    int arr[3] = {1, 2, 3};
    FILE *bf = fopen("data.bin", "wb");
    if (!bf) return 1;
    size_t wrote = fwrite(arr, sizeof arr[0], 3, bf);   // число ЭЛЕМЕНТОВ
    fclose(bf);

    FILE *bg = fopen("data.bin", "rb");
    if (!bg) return 1;
    int back[3] = {0};
    fread(back, sizeof back[0], 3, bg);
    fseek(bg, 0, SEEK_END);                       // переход в конец
    long size = ftell(bg);                        // размер файла
    rewind(bg);                                   // назад в начало
    fclose(bg);
    printf("wrote=%zu size=%ld back[2]=%d\n", wrote, size, back[2]);
    return 0;
}

Что здесь важно. fwrite и fread принимают размер элемента и количество элементов — благодаря этому возвращают «сколько удалось», и можно отличить частичное чтение от полного. В бинарном режиме сохраняется ровно то, что в памяти (для int — 4 байта подряд), без перевода строк. На каждом fopen висит обязанность проверить результат и затем сделать ровно один fclose — это и есть правило симметрии, как с malloc/free.

feof сообщает о конце файла после неудачного чтения, поэтому цикл строят на fgets/fread, а feof проверяют затем. Это очень частая ошибка: while (!feof(f)) { fgets(...); } обработает последнюю строку дважды, потому что флаг выставится только после попытки чтения за концом файла. Правильно: while (fgets(line, sizeof line, f)) { ... }.

Почему именно while (fgets(...)), а не while (!feof(f)). feof — это «ретроспективный» флаг: он взводится только когда предыдущая операция чтения не смогла прочитать байт и была именно из-за конца файла. Цикл «проверь feof ДО чтения» успеет последнюю успешную итерацию плюс ещё одну лишнюю (где fgets вернёт NULL, но вы уже не спросили). Идиома «проверить возвращаемое значение самой функции чтения» работает для fgets, fread, fscanf, getc и т. д. То же правило — в C++: while (std::getline(...)) — по той же причине.

Позиция задаётся через fseek(f, offset, SEEK_SET|SEEK_CUR|SEEK_END), текущее смещение читает ftell, а rewind возвращает в начало. Удаление и переименование — remove, rename. Текст ошибки по глобальной переменной errno печатает perror, а расшифровку даёт strerror(errno). Поскольку errno обнуляется не всеми функциями, надёжнее проверять возвращаемое значение, а errno смотреть только после явной ошибки. Когда ftell/fseek дают сюрпризы: для файлов, открытых в текстовом режиме, SEEK_END на Windows ведёт себя не так, как кажется: \n хранится на диске как два байта (\r\n), а в программе — один. Из-за этого ftell возвращает «логическую» позицию, отличающуюся от байтового смещения. Для честной позиции в текстовом файле используйте fgetpos/fsetpos с типом fpos_t либо сразу открывайте в бинарном режиме.

Текстовый или бинарный — как выбрать. Текстовый режим нужен для файлов, которые читает человек: конфигов, логов, CSV — там удобны fprintf/fgets. Бинарный режим ("rb"/"wb") сохраняет байты «как есть»: применяют для структур, изображений, протоколов. На Windows разница принципиальна: в текстовом режиме \n превращается в \r\n, что ломает побайтовое чтение. Универсальное правило: если данные должны остаться байт-в-байт — открывайте с b. На Linux/macOS режим «b» ничего не меняет, поэтому для переносимого кода безопаснее всегда писать b явно — привычка выручает на сдаче у преподавателя с Windows-машиной.

Теория алгоритмов (МГУ, курс «Алгоритмы и алгоритмические языки»)

Теоретический блок проверяют на коллоквиумах и в письменной части. Ниже — минимальный набор определений и результатов, который нужно уметь сформулировать своими словами. Правило ответа на теоретический вопрос: сначала определение, затем интуиция, затем формальная деталь, затем пример. Если забыли точную формулу функции переходов МТ, спасти ответ можно словами: «лента, головка, конечное управление» — это уже половина балла. Остальное (эквивалентность моделей и неразрешимость) выводится из определений, поэтому учите именно определения.

Зачем вообще нужен этот раздел. Это фундамент, на котором стоит весь курс: понятие «алгоритм» формализуется через машину Тьюринга, её вариации (НАМ) и мета-теории (тезис Чёрча–Тьюринга). Без этих определений нельзя понять, что такое «разрешимая задача», «NP-полнота» или «компилятор». Если вы освоите этот блок — дальнейшие темы (алгоритмы сортировки, графовые алгоритмы, синтаксический анализ) лягут гораздо легче, потому что вы будете понимать, что вообще значит «можно/нельзя вычислить».

Как готовиться к коллоквиуму — практический совет. Прочитайте определение, закройте шпаргалку и попробуйте сформулировать его устно вслух. Затем нарисуйте пример «руками» на бумаге (конфигурации МТ, шаги НАМ). На коллоквиуме 60 % успеха — это умение привести конкретный маленький пример и показать на нём работу модели: преподаватели любят спрашивать «а покажите, как ваша машина складывает 1+1».

Машина Тьюринга

Простыми словами. Машина Тьюринга — это идеализированный «робот с бесконечной бумажной лентой»: он смотрит на одну клетку, по таблице правил решает, что записать и куда сдвинуться, и так работает, пока не остановится. Это простейшая формальная модель, которой достаточно, чтобы описать любое вычисление, — поэтому именно на ней определяют понятие «вычислимая функция». Аналогия: МТ — это пишущая машинка с программой из «если видишь символ X — замени на Y и шагни вправо»; ничего умнее не нужно, чтобы смоделировать любую программу.

Ещё одна бытовая аналогия. Представьте себе кассу в магазине: лента — это касса, головка — это «глаза» кассира, программа — это инструкция, которую дали кассиру («если видишь яблоко — посчитай его и сдвинь ленту вправо»). Кассир работает, пока покупатели не закончатся или пока не дойдёт до «стоп-сигнала». Так же и МТ — она «тупая, но упорная»: шаг за шагом выполняет правила, и эта «тупость» гарантирует, что никакую вычислимую задачу мы не упустим.

Почему именно лента, а не оперативная память. Лента даёт два удобства: (1) адресация бесконечная — нам не нужно заранее думать, хватит ли памяти; (2) доступ строго последовательный, без случайного доступа — это «убирает инженерные детали» и оставляет только математическую суть алгоритма. Если бы МТ работала с оперативной памятью, мы бы обсуждали размер кэша и прочую аппаратную конкретику, а это нам не нужно для определения «алгоритм».

Машина Тьюринга (МТ) — формальная модель: M = (Q, Σ, Γ, δ, q₀, q_accept, q_reject), где Q — состояния, Σ — входной алфавит, Γ ⊇ Σ — ленточный алфавит с пустым символом ⊔, δ: Q × Γ → Q × Γ × {L, R, N} — функция переходов, q₀ — начальное состояние. Формулу стоит разобрать по частям: δ берёт пару (состояние, символ под головкой) и возвращает тройку (новое состояние, символ для записи, направление сдвига).

• Лента неограниченна в обе стороны, головка читает и пишет один символ за такт и сдвигается влево/вправо. Бесконечность ленты — это допущение «памяти хватит сколько угодно», а не реальное устройство. Почему это важно: реальная память ограничена, но для определения «алгоритм» мы хотим убрать ограничения и оставить только идею — если алгоритму нужно «больше памяти», он её «добудет», сдвинувшись по ленте. Так появляется возможность говорить о вычислимости «в принципе», без оглядки на железо.
• Конфигурация — полное описание текущего момента: состояние + содержимое ленты + позиция головки. Работа МТ — это последовательность конфигураций; именно конфигурациями удобно доказывать, что машина делает «то же самое». Зачем это нужно: преподаватели любят вопрос «что значит, что две машины эквивалентны?» Ответ — у них совпадают множества принимаемых слов; доказывают это обычно через индукцию по конфигурациям: «если у них одинаковая текущая конфигурация, то после шага снова одинаковая». Запомните слово «конфигурация» — оно ключевое.
• МТ разрешает язык, если останавливается на всех входах, принимая слова языка и отвергая остальные; полуразрешает, если останавливается только на принимаемых, а на «чужих» может зацикливаться. Разница между «разрешить» и «полуразрешить» — излюбленный вопрос коллоквиума. Как запомнить: «разрешить» = всегда есть ответ «да/нет» (типа суда: «виновен / невиновен»); «полуразрешить» = суд скажет «виновен», но если не виновен — может просто молчать до бесконечности. Полуразрешимость формально называется «рекурсивно перечислимое множество» — это важный термин для экзамена.
• Универсальная МТ (УМТ) моделирует любую другую МТ по её описанию — это идея интерпретатора и программируемости: одна машина может выполнить любую программу, если та записана на ленту. Именно из УМТ вырастает понятие «программа как данные» и, в конечном счёте, идея компьютера с хранимой программой (архитектура фон Неймана). Почему это революция: до УМТ каждая МТ умела делать только одно дело — складывать числа или проверять чётность. УМТ же умеет делать любое дело, если ей дать описание нужной МТ в виде кода. Это и есть фундаментальная идея «программа как данные» и рождения современных компьютеров.
• Пример для экзамена: МТ, прибавляющая единицу к числу в унарном коде (последовательность единиц). Идём вправо до пустого символа, заменяем его на 1 и останавливаемся. Проговорив такой пример, вы покажете, что понимаете модель, а не только определение. Пошагово, что говорить преподавателю: «Лента содержит 111⊔.... Стартуем с головки на первой единице. По правилу δ(q₀, 1) = (q₀, 1, R) идём вправо, оставляя единицы как есть. Дойдя до ⊔, выполняем δ(q₀, ⊔) = (q_accept, 1, N) — записываем 1 и останавливаемся. На ленте теперь 1111 — то есть число на 1 больше».

Нормальные алгоритмы Маркова

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

Ещё одна аналогия для запоминания. Представьте, что у вас есть текст на доске и стиратель. У вас есть список команд: «если видишь слово "кошка" — замени на "собака"». Вы идёте по тексту слева направо, находите самое первое подходящее место и заменяете. Команды просматриваются сверху вниз по списку. Когда ни одна команда не подходит — вы останавливаетесь. Это и есть НАМ в миниатюре.

Почему именно «нормальный». Название отражает, что стратегия применения правил зафиксирована однозначно (всегда берём первое правило, всегда заменяем самое левое). Это убирает свободу выбора и делает модель детерминированной. У «нормальных» алгоритмов нет «развилок» — за счёт этого они проще в анализе, и легче доказать эквивалентность с МТ.

Нормальный алгоритм Маркова (НАМ) — модель переписывания строк: конечный упорядоченный набор правил подстановки α → β (или α → ·β — заключительное, после которого работа немедленно прекращается).

• На каждом шаге берётся первое применимое правило (порядок правил — часть алгоритма, а не деталь) и самое левое вхождение образца заменяется. Отсюда название «нормальный»: правило применения фиксировано однозначно. Ловушка, на которой «горит» студент: студент говорит «алгоритм ищет любое подходящее место». Это неверно — алгоритм всегда выбирает самое левое вхождение. Если в строке abab правило ab → c, то результат — cab, а не abc (как бывает, если «выбирать любое»).
• Алгоритм останавливается, когда нет применимых правил или выполнена заключительная подстановка. Результат — строка, получившаяся на момент остановки. Важно: результат берётся в момент остановки, а не «после ещё одного шага». Это частая ошибка — студент пишет «после остановки ещё раз применяю правила». Не надо — НАМ останавливается, и финальная строка становится ответом.
• НАМ и МТ эквивалентны по вычислительной мощности: всё, что вычислимо на одной модели, вычислимо и на другой. Это важная часть тезиса Чёрча–Тьюринга, и на коллоквиуме просят подтвердить её примером (например, сложение унарных чисел правилами НАМ). Пример-«спасалочка»: сложение |+| даёт ||+. Правила: +1 → 1+, |+ → ·|+. Сначала + «добирается» вправо через все единицы (+|+ → 1|+1 → 11|+), затем «заедает» плюс справа (11+| + → 11||+), и заключительное правило останавливает процесс. Этот пример показывает, что НАМ может имитировать «перенос» без явных регистров.
• Типичная ошибка в ответе — путать «первое правило» с «любым подходящим» и забывать про «самое левое вхождение». Если отвечать расплывчато, преподаватель предложит применить правила вручную на конкретной строке — здесь неверный порядок сразу виден. Практический совет: на коллоквиуме тренируйтесь проговаривать «я беру правило номер 1, проверяю, есть ли самое левое вхождение; если нет — беру правило номер 2» — это показывает, что вы понимаете механику, а не только определение.

Тезис Тьюринга–Черча и проблема останова

Простыми словами. Тезис Чёрча–Тьюринга — это соглашение о том, что «вычислимо» = «вычислимо на машине Тьюринга»; строго доказать его нельзя, но все разумные модели вычислений (НАМ, λ-исчисление, рекурсивные функции) оказались эквивалентны. Проблема останова — знаменитое следствие: нельзя написать программу, которая для любой другой программы честно скажет, остановится та или нет. Аналогия: проблема останова — это «предсказатель будущего»; если бы он существовал, можно было бы построить программу, которая делает противоположное его предсказанию, — и предсказатель противоречил бы сам себе.

Ещё одна аналогия для проблемы останова. Представьте, что вам дали текст программы и спрашивают: «она когда-нибудь остановится?». Вы — компилятор/аналитик, который должен ответить «да» или «нет» без запуска программы. Оказывается, что для некоторых программ этот вопрос в принципе нельзя решить — никакой алгоритм не даст верный ответ на все случаи. Это не техническое ограничение (медленный компьютер, мало памяти) — это математическая невозможность.

Почему это слово «тезис», а не «теорема». Теорема — это строго доказанное утверждение. Тезис — это соглашение, которое нельзя доказать в принципе, потому что оно про «интуитивное» понятие (что такое алгоритм). Тезис говорит: «все наши интуитивные алгоритмы — это в точности то, что умеет МТ». Доказать это нельзя, потому что не определено формально, что такое «интуитивный алгоритм». Зато можно косвенно подтвердить: какую бы модель ни изобретали (НАМ, λ-исчисление, регистровые машины, машина Поста) — все они оказываются эквивалентны МТ. Это коллективное подтверждение и есть «доказательство» тезиса.

Тезис Чёрча–Тьюринга — интуитивное понятие «вычислимая функция» совпадает с вычислимостью на МТ (и в любой эквивалентной модели: НАМ, рекурсивные функции, λ-исчисление). Это не теорема, а соглашение о границах формализации: оно фиксирует, что мы считаем алгоритмом, и не позволяет «изобрести» более мощную модель вычислений. На экзамене обязательно подчеркните слово «тезис» — за фразу «теорема Чёрча–Тьюринга» могут снизить оценку. Ловушка для студента: студент на коллоквиуме говорит «это доказанная теорема». Преподаватель сразу поправит — и если вы не сможете объяснить, почему это не теорема, оценка снижается. Запомните формулировку: «это эмпирически подтверждённое соглашение, не имеющее формального доказательства».

Проблема останова: по описанию программы P и входа x определить, остановится ли P на x. Неразрешима. Доказательство от противного: пусть есть решающая машина H; построим D, которая при H(P,P) = "остановится" зацикливается, иначе останавливается. Тогда анализ D(D) противоречит определению H. Это классическая диагонализация — тот же приём, которым Кантор доказывал несчётность действительных чисел; на коллоквиуме полезно назвать это слово.

• Разбор доказательства по шагам, чтобы не запутаться в ответе:

  1. Допустим, существует H(P, x), которая всегда останавливается и возвращает «да», если P(x) останавливается, и «нет» — если зацикливается. Это наш «предсказатель».
  2. Строим программу D(P): если H(P, P) = "остановится", то D крутится в бесконечном цикле; иначе D сразу завершается.
  3. Теперь спрашиваем у H: что скажет H про D(D)?

• Если H говорит «D(D) остановится», то по определению D она должна зациклиться — противоречие.

• Если H говорит «D(D) зациклится», то D сразу остановится — опять противоречие.

  4. Вывод: такой H не существует, что и требовалось доказать. Эту цепочку на коллоквиуме полезно проговорить вслух шаг за шагом — преподаватели это ценят, потому что видят, что вы понимаете механизм доказательства, а не только заголовок.

• Следствия: неразрешимы проблема эквивалентности программ (делают ли две программы одно и то же), проверка «делает ли программа то, что нужно», и остановка произвольного кода. Отсюда же — невозможность универсального отладчика, который заранее найдёт все зависания. Следствие для практики: именно поэтому в реальных компиляторах и анализаторах есть false positives (предупреждения о тех местах, которые на самом деле корректны), но никогда нельзя гарантировать «всё, что не предупреждено — безопасно». Математики говорят: неразрешимость — это потолок, а не инженерная недоработка. Идеальный «отладчик всего» в принципе невозможен — это не вопрос развития технологий.

• Множества: разрешимые (есть МТ, всегда останавливающаяся с ответом «да/нет»), перечислимые (есть МТ, которая перечисляет элементы и может зацикливаться на не входящих), неперечислимые. Ключевое соотношение: разрешимое ⊂ перечислимое ⊂ все множества, причём включения строгие. Как запомнить соотношения: разрешимые ⊂ перечислимые ⊂ всех множеств. Строгость включений: (а) есть перечислимые множества, которые не разрешимы — например, «программа, которая останавливается на входе n» (как раз из проблемы останова, неразрешимая, но полуразрешимая); (б) есть множества вообще неперечислимые — например, дополнение к проблеме останова.

• Классы сложности: P — задачи, разрешимые за полиномиальное время; NP — задачи, решение которых можно проверить за полином; NP-полные — «самые трудные» в NP, к которым сводится любая задача из NP. Вопрос P = NP открыт: за его решение обещана премия в миллион долларов, и на экзамене достаточно сказать, что это одна из главных нерешённых проблем информатики. Полезные примеры для запоминания:

  • В P: сортировка массива за O(n log n), проверка связности графа, проверка чётности числа.
  • В NP (неизвестно, в P ли): задача коммивояжёра, SAT (выполнимость логической формулы), задача о клике.
  • Если вы слышите на экзамене «задача NP-полна» — это значит «она универсально трудна: если научимся быстро решать её, научимся быстро решать почти всё в NP». Не пытайтесь найти точный полиномиальный алгоритм — это «тот самый» открытый вопрос.

• Принципиальное замечание про P vs NP. В NP решение проверяется быстро (если дали ответ — можно проверить за полином). В P — решение находится быстро. Все знают, что P ⊆ NP (если решаем за полином, то и проверяем). Вопрос: верно ли, что NP ⊆ P? Большинство математиков считают, что нет — но строго доказать не могут. На коллоквиуме не врите в эту сторону: правильный ответ — «неизвестно, и за решение обещан миллион долларов (Clay Institute)».

БНФ и синтаксические диаграммы

Простыми словами. БНФ — это способ строго записать, из каких «кубиков» состоит правильная программа, — грамматика языка. Аналогия: школьная грамматика говорит «предложение = подлежащее + сказуемое»; БНФ говорит «программа = одно или несколько описаний». Она нужна, чтобы формально описать синтаксис и затем написать парсер (анализатор) — это тема курса «Алгоритмы и алгоритмические языки» на ВМК.

Зачем БНФ нужна на практике. Компилятор должен уметь отличать правильные программы от неправильных. Для этого ему нужна формальная грамматика — и БНФ исторически стала стандартом записи. Современные генераторы парсеров (yacc, bison, ANTLR) принимают грамматику в виде, очень близком к БНФ. То есть БНФ — это мост между «математическим описанием языка» и «реальным кодом компилятора».

Форма Бэкуса–Наура (БНФ) — метаязык описания синтаксиса:

<программа> ::= <описание> | <программа> <описание>
<описание>  ::= <тип> <идентификатор> ;
<тип>       ::= int | float | char

• ::= — «определяется как» (левая часть раскрывается через правую), | — альтернатива («или»), <...> — нетерминал (имя, которое нужно раскрыть дальше), обычные символы без скобок — терминалы (их пишем буквально). {} — повторение нуль и более раз, [] — необязательная часть. Как их отличать: нетерминал — это «короткое имя для куска», например <выражение>; терминал — это то, что уже похоже на кусок программы (if, ;, 123, +). Поначалу их путают, но привыкаешь: «нетерминал в треугольных скобках раскрываем дальше, терминал пишем как есть».
• Синтаксическая диаграмма (диаграмма Вирта) — графический эквивалент БНФ: терминалы в кружках, нетерминалы в прямоугольниках, альтернативы «развилками», а путь от входа к выходу задаёт допустимую запись. Так рисуют грамматику в учебниках и на защите. Когда удобнее диаграмма, а когда БНФ. Диаграмма — для небольшой грамматики, чтобы преподаватель сразу увидел структуру глазами. БНФ — для больших грамматик (десятки правил), её легче хранить в текстовом виде и подавать в генератор парсеров.
• Расширенная БНФ (РБНФ) добавляет повторы и опции прямо в запись ({ ... }, [ ... ]), поэтому она компактнее классической; именно её обычно и используют на практике. Пример из жизни: стандарты языков (например, Паскаль, Си) записаны в РБНФ-подобной форме, потому что там много повторяющихся частей: «список операторов — это ноль или более операторов подряд». Классическая БНФ потребовала бы рекурсивного определения, а РБНФ записывает это в одну строку.
• Типичная ошибка — путать синтаксис и семантику: БНФ описывает только форму («как записано»), но не смысл («что означает»). Например, что переменная объявлена раньше использования, БНФ выразить не может — это семантическое правило. Как провести границу на экзамене: спросите себя — «может ли компилятор-парсер проверить это правило, читая программу слева направо без анализа таблицы имён?» Если да — это синтаксис. Если нужно знать, что объявлено раньше, чем используется — это семантика. Семантические правила описываются отдельно (атрибутные грамматики, логика Хоара, контрактное программирование).
• Ещё одна частая ошибка новичков — левая рекурсия. Если правило <A> ::= <A> x | y, то разбор сверху вниз с рекурсивным спуском зациклится. Решение — переписать через правую рекурсию или использовать итерацию (<A> ::= y { x }). Преподаватели иногда специально дают такую грамматику, чтобы проверить, понимаете ли вы, как избежать зацикливания парсера.

Структуры данных и алгоритмы

Ядро практической части. Для каждой структуры — идея, ключевые операции, сложность и рабочий код. На экзамене почти всегда просят не просто назвать сложность, а обосновать её: почему вставка в список O(1), а поиск в нём O(n); почему хеш-таблица «в среднем O(1)», но может выродиться в O(n). Учите структуры вместе с их операциями, а не по отдельности — тогда ответ складывается сам. Ниже для каждой структуры сначала идёт аналогия и идея словами, затем код с комментариями и, где нужно, разбор типичной ошибки.

Зачем вообще нужны разные структуры. Любая программа — это компромисс между временем работы и памятью. Массив быстро даёт доступ по индексу, но медленно вставляет в начало. Список — наоборот. Хеш-таблица даёт почти мгновенный поиск, но плохо ведёт себя в худшем случае и тратит память «в пустоту». Поэтому на экзамене часто звучит контрольный вопрос: «А какую структуру вы бы выбрали для задачи X?» Ответ должен опираться на то, какие операции будут чаще: вставки, поиск, обход, удаление.

Односвязный список

Простыми словами. Список — это цепочка узлов, где каждый узел хранит данные и указатель на следующий. Аналогия: поезд из вагонов, где каждый вагон «знает» только следующий, но не предыдущий, — чтобы дойти до десятого вагона, нужно пройти первые девять. Отсюда главный компромисс: вставка и удаление дешёвы (нужно переставить пару указателей), а доступ по индексу дорог (O(n)), потому что адрес следующего узла иначе как перебором не узнать.

Почему именно так. Указатели в языке Си дают нам две суперсилы: (1) динамически расти — не надо заранее знать размер, как в массиве; (2) переставлять узлы без копирования данных — сменил два указателя, и всё. Плата — мы теряем «арифметику указателей»: нельзя сказать «дай i-й элемент» одной командой процессора, как a[i] = *(a + i) для массива. Каждый шаг по списку — это чтение указателя из памяти, а память может быть разбросана по куче (heap), поэтому ещё и кэш процессора работает хуже, чем по плотному массиву.

Список — узлы, связанные указателями; вставка и удаление за O(1) при известном месте, доступ по индексу — O(n).

#include <stdio.h>
#include <stdlib.h>

typedef struct Node { int data; struct Node *next; } Node;

// Вставка в начало за O(1): новый узел просто ссылается на бывшую голову.
// Функция возвращает НОВУЮ голову — иначе вызывающий её не увидит
Node *push_front(Node *head, int value) {
    Node *n = malloc(sizeof *n);
    if (!n) return head;                           // при ошибке возвращаем список как есть
    n->data = value;
    n->next = head;
    return n;                                      // новая голова
}

// Разворот за O(n) без дополнительной памяти: разворачиваем стрелки на ходу.
// Три указателя: prev (уже развёрнутая часть), head (текущий), next (сохраняем!)
Node *reverse(Node *head) {
    Node *prev = NULL;
    while (head) {
        Node *next = head->next;                   // 1. запомнили следующий узел
        head->next = prev;                         // 2. развернули стрелку назад
        prev = head;                               // 3. сдвинули prev
        head = next;                               // 4. перешли к следующему
    }
    return prev;                                   // prev — новая голова
}

// Освобождение списка: сохраняем next ДО free, иначе читаем освобождённую память
void free_list(Node *head) {
    while (head) { Node *t = head; head = head->next; free(t); }
}

int main(void) {
    Node *head = NULL;
    // push_front вставляет в начало, поэтому получается 5 4 3 2 1...
    for (int i = 1; i <= 5; i++) head = push_front(head, i);
    head = reverse(head);                          // ...а после разворота — 1 2 3 4 5
    for (Node *p = head; p; p = p->next) printf("%d ", p->data);
    putchar('\n');
    free_list(head);
    return 0;
}

Как объяснить таблицу. «O(n)» в строке «удаление по указателю» для односвязного списка означает, что даже имея указатель на узел, нельзя удалить его за O(1): нужно найти предыдущий узел, а для этого пройти список с начала. Двусвязный список решает именно эту проблему за счёт поля prev. У массива противоположный компромисс: доступ по индексу мгновенный (адрес вычисляется как base + i * sizeof), но вставка в начало требует сдвига всех элементов — O(n). Отсюда практический вывод: список выбирают, когда много вставок/удалений и мало поиска; массив — когда нужен быстрый доступ по индексу.

Дополнительно про сложность «O(n) / O(1) с хвостом». Если вместе с head хранить и tail (указатель на последний узел), то вставка в конец становится O(1) — иначе нам каждый раз пришлось бы идти до конца. Но тогда усложняется и освобождение списка: нужна функция, которая аккуратно обнулит оба указателя, иначе потеряем либо голову, либо хвост.

Типичная ошибка при работе со списком. Забыть вернуть новую голову: если вставить узел в начало и не присвоить head = push_front(head, x);, голова останется старой, а новый узел «потеряется» (и станет утечкой памяти). Второй частый баг — при удалении сдвинуть указатель обхода p = p->next там, где он не должен двигаться: это пропускает элементы. Третья, не менее частая ошибка — p = p->next после free(p): к этому моменту память уже отдана куче, и чтение из неё — undefined behavior (UB), компилятор это не поймает, программа будет работать «иногда».

Практический совет. Полезно сразу нарисовать список на бумаге с тремя-четырьмя узлами, отметить стрелки next и пройти свой код «карандашом» — 90% ошибок со списками видны глазом, а компилятор их не видит вовсе.

Двусвязный список

Простыми словами. В двусвязном списке каждый узел хранит указатели в обе стороны — на предыдущий и на следующий. Аналогия: вагоны с двумя сцепками, поэтому поезд можно собирать и разбирать с любого конца, а «выцепить» вагон, зная его самого, — мгновенно. Плата за удобство — лишний указатель в каждом узле: памяти тратится больше, а при вставке/удалении нужно аккуратно обновить вдвое больше ссылок (главный источник ошибок).

Почему именно так. Если в односвязном списке «узнать предыдущий узел» нельзя без полного обхода, то в двусвязном достаточно одного разыменования указателя prev->next. Это и даёт O(1) на удаление по указателю. Но за это платим памятью: ещё 8 байт (на 64-битной системе) на каждый узел — для миллиона элементов это уже ~8 МБ дополнительно, что иногда критично. На экзамене достаточно сказать «O(1) за счёт хранения обратного указателя, цена — +sizeof(pointer) на узел».

Каждый узел хранит prev и next — удаление по указателю и обход в обе стороны за O(1) при наличии самого узла.

#include <stdio.h>
#include <stdlib.h>

typedef struct DNode { int data; struct DNode *prev, *next; } DNode;

DNode *dlist_insert(DNode *head, int value) {      // вставка в начало, O(1)
    DNode *n = malloc(sizeof *n);
    if (!n) return head;
    n->data = value;
    n->prev = NULL;                                // у нового первого узла предка нет
    n->next = head;
    if (head) head->prev = n;                      // старый первый теперь смотрит назад на n
    return n;
}

// Указатель на указатель (DNode **head) нужен, чтобы изменить саму голову:
// при удалении первого узла голова сдвигается
void dlist_remove(DNode **head, DNode *n) {
    if (n->prev) n->prev->next = n->next;          // «перепрыгнули» узел слева
    else         *head = n->next;                  // удаляем первый — меняем head
    if (n->next) n->next->prev = n->prev;          // «перепрыгнули» узел справа
    free(n);                                       // память узла освобождаем
}

int main(void) {
    DNode *head = NULL;
    for (int i = 1; i <= 3; i++) head = dlist_insert(head, i);   // 3 2 1
    dlist_remove(&head, head->next);               // удалили средний узел (2)
    for (DNode *p = head; p; p = p->next) printf("%d ", p->data);   // 3 1
    putchar('\n');
    return 0;
}

Почему в dlist_remove передан DNode **head. Передать DNode *head означало бы передачу копии указателя — мы могли бы менять сам список, но не могли бы сказать вызывающему коду «у тебя теперь новая голова». Поэтому, когда нужно менять саму переменную-указатель (например, при удалении первого узла), берётся указатель на указатель: ** → «дай мне возможность переписать твой указатель». На экзамене это любимая тема — будьте готовы объяснить, чем Node *head отличается от Node **head.

Типичная ошибка. Забыть обновить prev у соседа: например, при удалении узла поправили n->prev->next = n->next, но не поправили n->next->prev = n->prev — список «расползается», и при обходе назад программа зацикливается либо падает с SIGSEGV. Вторая типичная ошибка — if (n->prev) и if (n->next) написаны раздельно, а на экзамене просят именно аккуратно обработать оба случая (первый/последний узел).

Когда выбирать двусвязный, а когда односвязный. Если нужен только обход «вперёд» и вставки в начало — хватит односвязного (меньше памяти и меньше шансов ошибиться). Двусвязный оправдан, когда реально нужны: удаление по известному узлу, обход в обе стороны, LRU-кеш, undo/redo в редакторе.

Стек, очередь, дек

Простыми словами. Стек и очередь — это одни и те же данные, но с разным порядком доступа. Стек (LIFO, last in — first out) — как стопка тарелок: кладёте сверху и берёте сверху, поэтому последний добавленный элемент уходит первым. Очередь (FIFO, first in — first out) — как очередь в столовой: кто раньше встал, тот раньше обслужен. Дек — двухсторонняя очередь: подходить можно и с начала, и с конца. Главное, что нужно назвать на экзамене, — все операции выполняются за O(1), и именно поэтому эти структуры незаменимы в обходах графа и разборе выражений.

Почему O(1). У стека и очереди доступ строго к одному краю (у стека — всегда к вершине, у очереди — к голове и хвосту, но к «середине» доступа нет). Это значит, что не нужно искать элемент — мы уже знаем, где он. Перестановка одного-двух указателей — и готово. Линейный поиск тут не появляется именно потому, что поиск этим структурам не полагается: если нужен поиск — это уже другая структура (хеш-таблица, дерево).

Когда какую структуру использовать. Стек — рекурсия, разбор скобок, обратная польская запись, отмена действий (Ctrl+Z). Очередь — обход графа в ширину (BFS), планировщик задач, обработка запросов сервером, любая модель «пришёл раньше — обслужен раньше». Дек — скользящее окно, palindrome-проверка, поддержка максимума на отрезке за O(1). Стек (LIFO, Last In — First Out) — структура данных «последним вошёл — первым вышел»: push кладёт элемент на вершину, pop снимает его оттуда же. Аналогия из жизни: стопка тарелок в буфете — вы всегда берёте верхнюю, и новую кладёте наверх. Обе операции выполняются за O(1), потому что вершина всегда известна (хранится как индекс или указатель) и перебирать ничего не нужно. Почему так: стек — это и есть «упорядоченный по времени поступления» доступ, и его сила в том, что вершина доступна мгновенно, без поиска.

Очередь (FIFO, First In — First Out) — структура данных «первым вошёл — первым вышел»: enqueue добавляет элемент в хвост, dequeue забирает из головы. Аналогия: очередь людей к кассе — кто встал раньше, тот раньше уйдёт. Это фундаментальное отличие от стека: LIFO «помнит последнее», FIFO «помнит первое». Понимание разницы критично для экзамена — на нём любят спрашивать, что вы примените в конкретной задаче: стек или очередь.

Дек (deque, double-ended queue) — двусторонняя очередь: можно вставлять и удалять элементы с обоих концов (часто реализуется через массив с двумя указателями «голова» и «хвост», которые могут «заворачиваться»). Аналогия: живая очередь, в которой разрешено входить и выходить как спереди, так и сзади. Применяется в алгоритмах скользящего окна, в undo/redo (отмена и повтор действий), в планировщиках операционной системы.

#include <stdio.h>
#include <stdlib.h>
#include <stdbool.h>

#define CAP 8

// Стек на массиве фиксированной ёмкости: top — индекс следующей свободной ячейки
typedef struct { int data[CAP]; int top; } Stack;
bool  push(Stack *s, int v) { return s->top < CAP ? (s->data[s->top++] = v, true) : false; }
int   pop(Stack *s)         { return s->top > 0 ? s->data[--s->top] : -1; }
bool  empty(Stack *s)       { return s->top == 0; }

// Очередь КОЛЬЦЕВАЯ: после конца массива tail и head заворачиваются в 0,
// иначе место в буфере быстро кончится, хотя элементы уже извлечены
typedef struct { int data[CAP]; int head, tail; } Queue;
void enqueue(Queue *q, int v) { q->data[q->tail] = v; q->tail = (q->tail + 1) % CAP; }
int  dequeue(Queue *q)        { int v = q->data[q->head]; q->head = (q->head + 1) % CAP; return v; }

int main(void) {
    Stack s = {.top = 0};                          // .top = 0 — стек пуст
    push(&s, 1); push(&s, 2); push(&s, 3);
    while (!empty(&s)) printf("%d ", pop(&s));     // 3 2 1 — LIFO наглядно
    putchar('\n');

    Queue q = {.head = 0, .tail = 0};              // .head == .tail — очередь пуста
    enqueue(&q, 10); enqueue(&q, 20);
    printf("%d %d\n", dequeue(&q), dequeue(&q));   // 10 20 — FIFO
    return 0;
}

Почему именно так, а не иначе. В стеке top хранит позицию следующей свободной ячейки (а не последней занятой) — это удобно, потому что проверка на переполнение превращается в одно сравнение с CAP, а на пустоту — в одно сравнение с нулём. В кольцевой очереди head и tail — индексы, которые «двигаются по кругу» через % CAP; пустая очередь определяется равенством head == tail, а полная — условием (tail + 1) % CAP == head (одну ячейку оставляют «пустой», чтобы отличить полную от пустой — это классический трюк, его спрашивают отдельно). Не путайте «где вершина» и «где хвост»: в стеке это одно и то же место, в очереди — противоположные концы.

Стек применяют для проверки скобочной последовательности, обхода в глубину (DFS), вычисления выражений, отката рекурсии; очередь — для обхода в ширину (BFS) и планирования задач (в т. ч. в планировщике ОС и в очереди печати).

Задача «проверить скобки» (частый экзаменационный вопрос). Идея в одном предложении: открывающую скобку «запоминаем», закрывающую — сверяем с последней запомненной. Аналогия из жизни: представьте текстовый редактор с вложенными скобками — при вводе ) программа должна проверить, что последняя введённая вами открывающая скобка была именно (, иначе вложенность нарушена. Для этого идеально подходит стек: открывающие скобки кладём в стек, а закрывающие — сравниваем с вершиной. Если вершина не соответствует или стек пуст при закрывающей — последовательность неверна; в конце стек должен быть пуст. Алгоритм за O(n): пройти по строке, push для (, [, {; для ), ], } проверить вершину и pop. Почему стек, а не просто счётчик? Потому что скобки могут быть разных типов: (]) — неверно, хотя количество открывающих и закрывающих совпадает. Счётчик этого не поймает, а стек — поймает, потому что хранит тип последней открывающей скобки.

Типичная ошибка № 1 (самая частая). Не проверять пустоту стека перед pop. Выражение начинается с )]} — стек пуст, а мы пытаемся снять вершину. Программа либо выдаст мусор, либо упадёт (выход за границу массива). Обязательно перед pop пишите if (empty(&s)) return false;.

Типичная ошибка № 2. Не проверять, что после обработки строки стек пуст. Это пропускает лишние открывающие скобки — например, (( оставит в стеке (, и без финальной проверки алгоритм скажет «верно». Всегда делайте «заключительный тест» в самом конце функции — это 1 строка, но она ловит класс ошибок, который иначе выглядит «невидимым».

Типичная ошибка № 3. Забыть про соответствие типов скобок — проверять только количество, а не парность. Стек это лечит естественно, но если вы пишете «в лоб» через счётчики, легко упустить.

Практический совет. На экзамене оформите проверку соответствия отдельной функцией bool is_matching(char open, char close) — это делает код чище и сразу показывает преподавателю, что вы понимаете суть, а не «зазубрили switch-case». Пара строк экономии на экзамене оборачивается парой баллов.

Разница стека на массиве и на списке. Реализация на массиве проще и быстрее (хорошая локальность кеша — элементы лежат подряд, процессор их предзагружает), но имеет фиксированную ёмкость (или требует перевыделения памяти при росте — а это дорого, потому что нужно копировать всё). Реализация на связном списке ограничена только объёмом оперативной памяти, динамически растёт без копирования, но тратит дополнительную память на указатели (×2 от размера данных) и медленнее из-за плохой локальности кеша (узлы разбросаны по памяти, каждый доступ — потенциальный cache miss). На экзамене укажите оба варианта и обязательно проговорите компромисс: «простой массив — быстрее и проще, но ограничен; связный список — гибче по размеру, но платим памятью и временем». Это покажет системное понимание, а не механическое знание кода.

Польская запись

Простыми словами. Обратная польская (постфиксная) запись — это способ записать арифметическое выражение без скобок: сначала операнды, потом операция. Аналогия: так работает калькулятор в обратной польской логике (HP-12C, Forth, советские «Электроника МК-61») — вы вводите числа, они накапливаются в стеке, а когда вы нажимаете операцию, она берёт два верхних числа и кладёт результат обратно. Выражение (3 + 4) * 5 превращается в 3 4 + 5 *, и порядок вычислений задаётся сам собой — никакие скобки не нужны. Эта задача почти обязательна в билетах МИФИ, потому что объединяет стек, разбор строк и вычисления в одной точке и проверяет, понимает ли студент, почему порядок именно такой.

Почему это вообще работает. Каждый оператор «ждёт», пока у него появятся операнды — а они появляются строго в порядке «снизу стека — раньше, сверху — позже». Поэтому b - a в выражении 5 3 - читается как «возьми 5 и 3, вычти из первого второе» — то есть 5 - 3 = 2. Порядок операндов определяется их расположением в исходном выражении, а не скобками. Скобки нужны были в инфиксной записи только затем, чтобы сказать «сначала сложи», а в постфиксной записи это сделано «само» через позицию оператора.

Обратная польская (постфиксная) запись — операторы записываются после операндов, скобки не нужны. Вычисляется одним проходом по строке со стеком; перевод из привычной инфиксной формы (с операторами между операндами) — алгоритм Дейкстры, известный как «сортировочная станция» (shunting-yard algorithm), потому что он расставляет операторы «в правильном порядке», как вагоны на сортировочной станции.

Пошаговый алгоритм вычисления (запомните порядок):

1. Заводим пустой стек чисел.
2. Читаем выражение слева направо по токенам (число или оператор).
3. Если токен — число, кладём его в стек (push).
4. Если токен — оператор: извлекаем два числа — сначала правое b, потом левое a — вычисляем a op b (порядок критичен для - и /) и кладём результат обратно в стек.
5. В конце в стеке должен остаться ровно один элемент — это и есть результат.

#include <stdio.h>
#include <stdlib.h>
#include <ctype.h>
#include <string.h>

// Вычисление постфиксного выражения: "3 4 + 5 *" => 35
int eval_rpn(const char *expr) {
    int st[64], top = 0;                 // стек чисел; top — индекс вершины + 1
    char buf[64];
    while (*expr) {
        if (isspace((unsigned char)*expr)) { expr++; continue; }   // пробелы пропускаем
        if (isdigit((unsigned char)*expr)) {
            // Собираем число из подряд идущих цифр
            int i = 0;
            while (isdigit((unsigned char)*expr)) buf[i++] = *expr++;
            buf[i] = '\0';                // замыкаем строку, иначе atoi прочитает мусор
            st[top++] = atoi(buf);
            continue;
        }
        // Оператор: СНАЧАЛА снимаем правое число b, потом левое a —
        // для вычитания и деления порядок критичен
        int b = st[--top], a = st[--top];
        switch (*expr++) {
            case '+': st[top++] = a + b; break;
            case '-': st[top++] = a - b; break;
            case '*': st[top++] = a * b; break;
            case '/': st[top++] = a / b; break;
        }
    }
    return st[--top];                    // в стеке остался ровно один результат
}

int main(void) {
    printf("%d\n", eval_rpn("3 4 + 5 *"));    // 35
    return 0;
}

Подробнее про порядок операндов. Когда в стеке лежит ... a, b (a глубже, b на вершине), оператор берёт их в порядке «верхний, потом нижний». То есть сначала b = pop(), потом a = pop(). Почему именно так? Потому что в постфиксной записи операнды идут в том порядке, в каком их «увидел» оператор — а оператор стоит после них. Если вы пишете 5 3 -, то 5 встретилось раньше, 3 — позже. Когда - сработает, 5 уже лежит в стеке глубже, 3 — наверху. Оператор должен взять «верхний — это правый, нижний — это левый» и посчитать 5 - 3. Эта связь «позиция в выражении ↔ глубина в стеке» — ключ ко всей задаче.

Типичная ошибка при решении № 1 (самая частая!). Перепутать порядок операндов: если для - взять b - a вместо a - b, то "5 3 -" даст -2 вместо 2. На экзамене за это снимают баллы — запишите в комментарии: «b снимаем первым, потому что он на вершине». Это маленький комментарий, но он покажет, что вы понимаете, почему именно так, а не наоборот.

Типичная ошибка № 2. Не проверять пустоту стека перед операцией: некорректное выражение (например, «+» без чисел или «3 +») приведёт к чтению за границей массива (top--, когда top == 0) — это UB (undefined behavior), программа может вести себя непредсказуемо: выдать мусор, зациклиться или упасть. В хорошем решении перед pop стоит if (top < 2) return ERROR; — две числа нужно минимум.

Типичная ошибка № 3. Не замыкать buf нулём: без buf[i] = '\0' функция atoi прочитает «хвост» предыдущего числа, и вы получите мусор вместо правильного значения. Это типичная сишная ошибка — atoi не знает длины строки, она идёт до нулевого байта. Если забыли — следующее число окажется «склеенным» с предыдущим.

Типичная ошибка № 4. Забыть, что isspace/isdigit принимают int, причём значение должно быть в диапазоне unsigned char или EOF. Если *expr равен EOF (-1) или любому байту > 127, без приведения к (unsigned char) можно получить UB. В коде это isspace((unsigned char)*expr) — обратите внимание на приведение типа, его пропускают почти все.

Финальная проверка на экзамене. После обработки всей строки в стеке должен остаться ровно один элемент. Если их больше — где-то пропущен оператор или есть «лишние» числа; если стек пуст — операторов было слишком много. Можно добавить return top == 1 ? st[0] : ERROR; — это простой способ проверить корректность входа и сразу поднять тревогу, если данные испорчены. На экзамене такая проверка занимает одну строку, а преподаватель видит, что вы понимаете, что бывают некорректные входы.

Сортировки

Простыми словами. Сортировка — это упорядочивание элементов по некоторому ключу; разные алгоритмы отличаются тем, как быстро они работают на разных данных и сколько дополнительной памяти берут. Устойчивость означает, что равные элементы сохраняют исходный относительный порядок. Аналогия: если вы сортируете стопку карточек сначала по имени, потом по курсу, устойчивый алгоритм сохранит алфавитный порядок имён внутри одного курса — а неустойчивый может перемешать. Это не «мелочь»: устойчивость прямо названа в экзаменационной таблице, и её спрашивают почти всегда — без неё ответ про сортировку считается неполным.

Аналогии из жизни, чтобы запомнить навсегда. Пузырьковая сортировка — это как «всплытие» лёгких (маленьких) элементов: на каждом проходе более «лёгкие» элементы постепенно перемещаются к концу массива, как пузырьки воздуха в воде. Сортировка вставками — как то, как вы сортируете карты в руке: берёте следующую карту и вставляете её в нужное место уже отсортированной части. Сортировка выбором — как «выбери минимум и поставь в начало», повторяй; просто, но неустойчиво (см. ниже). Быстрая сортировка — это «разделяй и властвуй»: делим массив на «меньше опорного» и «больше опорного», потом рекурсивно сортируем каждую часть. Сортировка слиянием — тоже «разделяй и властвуй», но «склеиваем» обратно уже отсортированные куски через вспомогательный массив.

Как читать сложности на практике. Запись O(n²) означает: при удвоении размера массива время вырастет примерно вчетверо (потому что (2n)² = 4n²), а O(n log n) — немногим более чем вдвое (потому что 2n·log(2n) ≈ 2n·(log n + 1)). Поэтому на 10 000 элементов пузырёк и быстрая сортировка различаются не «в два раза», а на порядки — пузырьку нужны миллионы операций, быстрой — около 130 000. Это разница между секундой и минутой на практике, и между «сдать на стенде» и «ждать ночь». На экзамене эту разницу любят проверять вопросом «почему O(n log n) быстрее O(n²)?».

Почему память различается. «Память O(log n)» у быстрой сортировки — это глубина рекурсии (в среднем она пропорциональна log n, потому что каждый уровень рекурсии делит массив пополам); дополнительных массивов под данные нет. «O(n)» у слияния — это вспомогательный буфер, который приходится выделять целиком для слияния двух половин. На экзамене любят уточняющий вопрос: «а можно ли сортировку слиянием сделать in-place?» — технически да (существуют алгоритмы сложности O(n log² n) без допмассива), но она становится значительно сложнее и медленнее, поэтому в учебных целях используют O(n). Запомните эту связь: «меньше памяти — обычно сложнее или медленнее».

Устойчивость важна, когда элементы — записи с несколькими полями. Классический пример: у вас список студентов (имя, курс). Вы отсортировали его по имени. Теперь нужно отсортировать по курсу, сохраняя алфавитный порядок внутри одного курса. Это можно сделать одной сортировкой по составному ключу (курс, имя), либо двумя сортировками: сначала по имени, потом по курсу устойчивой сортировкой. Второй вариант возможен только с устойчивым алгоритмом — иначе вторая сортировка «сломает» алфавитный порядок из первой.

Худший случай быстрой сортировки — уже отсортированный массив при выборе крайнего опорного элемента (всегда первого или всегда последнего): разбиение каждый раз даёт подмассив из n-1 элемента и пустой второй, и глубина рекурсии становится O(n), а общее время — O(n²). Лечится выбором среднего или случайного pivot (или «медианы трёх» — берём первый, средний и последний элементы, выбираем из них медиану), тогда средняя оценка O(n log n) сохраняется даже на почти отсортированных или обратно отсортированных данных. На экзамене обязательно проговорите эту связь: O(n²) в худшем возникает не «случайно», а из-за неудачного выбора опорного элемента — и решение состоит в том, чтобы pivot выбирать «по-умному». Это показывает, что вы понимаете, почему алгоритм работает, а не просто выучили таблицу.

Почему сортировка выбором неустойчива. При выборе минимума вы меняете его с текущей позицией — а эта замена может «перепрыгнуть» через равный элемент и изменить их относительный порядок. Классический пример: сортируем [2a, 1, 2b] (где 2a и 2b равны по ключу, но это разные элементы). При первом проходе ищем минимум — это 1, меняем его с 2a и получаем [1, 2a, 2b]. Вроде всё хорошо, но если бы 2a стоял правее 2b, после обмена с 1 они бы поменялись местами и 2b оказался бы раньше 2a — порядок равных элементов нарушен. Устойчивая версия сортировки выбором существует, но требует дополнительной памяти (вставлять минимум в начало, сдвигая остальные), и на практике почти никогда не используется.

#include <stdio.h>

void swap(int *a, int *b) { int t = *a; *a = *b; *b = t; }

void bubble_sort(int *a, int n) {                  // O(n^2), на почти отсортированных — O(n)
    for (int i = 0; i < n - 1; i++) {
        int swapped = 0;
        for (int j = 0; j < n - 1 - i; j++)
            if (a[j] > a[j + 1]) { swap(&a[j], &a[j + 1]); swapped = 1; }
        if (!swapped) break;
    }
}

void insertion_sort(int *a, int n) {               // устойчива, хороша для малых n
    for (int i = 1; i < n; i++) {
        int key = a[i], j = i - 1;
        while (j >= 0 && a[j] > key) { a[j + 1] = a[j]; j--; }
        a[j + 1] = key;
    }
}

void selection_sort(int *a, int n) {               // минимум swaps: O(n) обменов
    for (int i = 0; i < n - 1; i++) {
        int m = i;
        for (int j = i + 1; j < n; j++) if (a[j] < a[m]) m = j;
        if (m != i) swap(&a[i], &a[m]);
    }
}

// Схема Ломуто: опорный — последний элемент.
// i — граница «области элементов <= pivot»; когда встречаем меньший,
// расширяем область и меняем местами
int partition(int *a, int lo, int hi) {
    int pivot = a[hi], i = lo - 1;
    for (int j = lo; j < hi; j++)
        if (a[j] <= pivot) swap(&a[++i], &a[j]);
    swap(&a[i + 1], &a[hi]);                       // ставим pivot на своё место
    return i + 1;                                  // его индекс: слева меньше, справа больше
}

// Быстрая сортировка: рекурсивно делим массив вокруг pivot.
// Риск O(n^2) на отсортированных данных — лечится случайным pivot
void quick_sort(int *a, int lo, int hi) {
    if (lo < hi) {                                 // база: 0 или 1 элемент уже отсортированы
        int p = partition(a, lo, hi);
        quick_sort(a, lo, p - 1);                  // левая часть
        quick_sort(a, p + 1, hi);                  // правая часть
    }
}

void merge(int *a, int lo, int mid, int hi, int *buf) {
    int i = lo, j = mid + 1, k = lo;
    while (i <= mid && j <= hi) buf[k++] = (a[i] <= a[j]) ? a[i++] : a[j++];
    while (i <= mid) buf[k++] = a[i++];
    while (j <= hi)  buf[k++] = a[j++];
    for (i = lo; i <= hi; i++) a[i] = buf[i];
}

void merge_sort(int *a, int lo, int hi, int *buf) {
    if (lo < hi) {
        int mid = lo + (hi - lo) / 2;
        merge_sort(a, lo, mid, buf);
        merge_sort(a, mid + 1, hi, buf);
        merge(a, lo, mid, hi, buf);
    }
}

int main(void) {
    // Внимание: buf — размером как минимум с исходный массив (память O(n))
    int a[] = {5, 2, 9, 1, 5, 6}, n = 6;
    int buf[6];
    merge_sort(a, 0, n - 1, buf);                  // устойчивая сортировка слиянием
    for (int i = 0; i < n; i++) printf("%d ", a[i]);   // 1 2 5 5 6 9
    putchar('\n');
    return 0;
}