Есть классическая проблема: изолированные процессы — хорошо для надёжности, но хочется иногда позвать функцию из соседа, как будто она лежала в той же библиотеке. Стандартные IPC — это всегда протокол: описал интерфейс, сгенерировал стабы, поднял сервер, прописал адреса. simplerpc предлагает путь короче: ты пишешь обычную функцию на Си, линкуешь библиотеку — и она автоматически становится RPC-методом, доступным другим процессам на той же машине.

Архитектура держится на трёх решениях. Во-первых, данные едут не через сокет, а по разделяемой памяти — SHMEM. Аргументы вызова лежат в общем сегменте, отображённом по одному виртуальному адресу во всех процессах, и копирования между адресными пространствами нет. Сокет используется только для сигналов: регистрация функций, передача дескриптора памяти (SCM_RIGHTS), обнаружение смерти клиента. Во-вторых, свой аллокатор — транзакционный TLSF с откатом при падении процесса. Межпроцессный мьютекс встроен прямо в структуру пула, а если владелец мьютекса погибает, следующий автоматически откатывает незавершённую транзакцию. Пул консистентен без внешнего сторожа. В-третьих, вместо стандартных примитивов синхронизации — POSIX-семафоры в разделяемой памяти и lock-free MPMC-очередь для передачи задач от клиента к воркерам.

Но самое интересное — как демон оказывается в системе. Исполняемый файл демона не лежит на диске. Он встроен в libsrpc.so в виде C-массива, записывается в анонимный memfd целиком в оперативной памяти и запускается через fexecve(). При загрузке библиотеки любым приложением автоматически форкается демон. Если процессов несколько — проигравший гонку bind() на абстрактном Unix-сокете молча завершается. Когда последний клиент отключается — демон выходит, а память исчезает вместе с последней ссылкой на memfd. Никакого PID-файла, никакого init-скрипта, никакого сервиса. Библиотека сама себя разворачивает.

Библиотека организована так: guard daemon (фоновый координатор), транспорт (Unix-сокеты и SCM_RIGHTS), аллокатор TLSF с транзакциями, сборщик мусора в разделяемой памяти с hazard pointers, RPC через X-макросы (один файл — единственный источник истины), динамическая линковка через weak alias, дескрипторы процессов и потоков, lock-free очереди и синхронизация. Всё это — в bench/ можно найти бенчмарки, если захотите сравнить сами.

Попробовать три команды: mkdir build && cd build && cmake .. && make, затем в одном терминале ./log, в другом ./app. Готово.

Ограничения: только Linux, только локальные процессы на одной машине, ранняя стадия развития — API стабильностью не отличается. Функции с переменным числом аргументов не поддерживаются, указатели осмыслены только если адресуют разделяемый пул.

Репозиторий: github, лицензия Apache-2.0. Если интересно — смотрите код на Си.

Перевод и пересказ короткой заметки автора Redis для русскоязычной аудитории — четыре месяца разработки, изменение внутренней архитектуры в середине пути, ARGREP с регулярными выражениями через TRE и общий вывод про связку «человек + AI» в инфраструктурном коде.

Что вышло. В Redis приземлился новый нативный тип Array с поддержкой числового индекса как части семантики (PR #15162). Четыре месяца работы; команды ARSET, ARSCAN, ARPOP, ARGREP, ARINSERT.

Спецификация — первое. Месяц ушёл на ручное написание спецификации: обоснование типа, C-структуры, разрежённое представление, семантика курсора для ring buffer и ARINSERT. Сначала с Opus, потом с GPT 5.3 / Codex.

Архитектура поменялась в середине. Изначально были два уровня директорий и slices двух типов (sparse и dense) — этого не хватило для ARSET с очень большими индексами. Перешёл на «super directory of sliced dense directories» с slice по 4096 элементов. Без AI «срезал бы углы» — с AI пошёл на extra mile.

ARGREP с regex. При тестировании Сальваторе начал хранить файлы Markdown в Array — для своей базы знаний. Так появилась идея ARGREP. Взял библиотеку TRE (за гарантии по времени против патологических паттернов), оптимизировал её для матчинга foo|bar|zap и закрыл несколько проблем безопасности.

Главный вывод. AI — не замена человека в системном программировании, но «safety net» для громоздких задач (32-битная поддержка, тесты алгоритмов) и виртуальная команда ревью. Спецификация по-прежнему пишется человеком, и она же ключ ко всем последующим этапам.

Месяц первый: спецификация руками

Сальваторе подчёркивает: даже с AI первый месяц был полностью ручной работой над спецификацией. Документ описывает обоснование нового типа, C-структуры, разрежённое представление, точную семантику курсора для ring buffer и команды ARINSERT.

Дальше пошёл back-and-forth с моделью: сначала с Claude Opus, потом, когда вышел GPT 5.3, переключился на Codex. С тех пор все системные задачи делает только на GPT 5.x. Промежуточные обсуждения с моделью качественно меняли спецификацию: интеллектуальные вызовы про лучший дизайн, что переусложнено, что — недостаточно проработано.

Месяцы второй и третий: автокодинг и пересмотр архитектуры

Со второго месяца Сальваторе начал реализацию через automatic programming (его термин для написания кода с AI-ассистентом): постоянное ревью того, что пишет модель. И тут наткнулся на проблему — выбранный уровень индирекции оказался неправильным.

Изначально была схема: два уровня директорий и slices (sparse и dense). Этого не хватало для сценария вида ARSET myarray 293842948324 foo — то есть когда индекс большой, а массив должен оставаться разрежённым без огромных аллокаций.

Поскольку у меня был AI, я не пошёл на компромисс — решил пройти extra mile.

Под определёнными условиями структура данных меняет внутреннюю форму, превращаясь в super directory из sliced dense directories, которые в свою очередь указывают на сами array slices (по 4096 элементов на slice по умолчанию).

Это и дало одновременно «как настоящий массив» с точки зрения внутреннего представления, и нужные характеристики по памяти. ARSCAN и ARPOP теперь сканируют существующие массивы за время, пропорциональное числу элементов, а не длине диапазона.

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

Появление ARGREP — от своей задачи к команде

Когда стресс-тестирование Array на разных кейсах подтвердило, что структура годится, Сальваторе начал моделировать сценарии использования. И тут, как часто бывает, личная задача подсказала фичу: он начал хранить файлы Markdown прямо в массивах — потому что они хорошо ложатся в этот тип.

Параллельно работал с агентами на других задачах и понял, что ему нужна централизованная база знаний из файлов Markdown под нужные навыки. Из своей потребности родился ARGREP. Но захотелось не просто поиска по подстроке — захотелось регулярных выражений.

Выбор библиотеки regex — отдельная история. Сальваторе остановился на TRE от Ville Laurikari: когда regex встраивается в Redis, важно гарантировать отсутствие патологических паттернов по времени и памяти. Но у TRE оказалась неэффективность в одном специфичном и очень полезном кейсе — матчинг alternation вида foo|bar|zap.

С помощью GPT он оптимизировал библиотеку для этого кейса, заодно зафиксил несколько потенциальных проблем безопасности и расширил тесты. После этого ARGREP с честным regex был готов к мержу.

Главное наблюдение: AI как safety net

Сальваторе формулирует главный вывод так: для high-quality системного программирования по-прежнему нужно быть полностью вовлечённым — но AI расширил «зону комфорта». Без него Сальваторе не пошёл бы на тот уровень сложности, который выбрал для нового типа.

AI выступил safety net в двух конкретных аспектах:

• Громоздкие задачи без выгорания. Например, поддержка 32-битной архитектуры, которую он добавил и протестировал отдельно. Это та работа, что обычно отнимает мотивацию и силы — с AI она прошла без обычного истощения.
• Виртуальная команда ревью, которая отлавливает очевидные баги в сложных алгоритмах. Не замена тестам и не замена самому Сальваторе — но дополнительный слой, который ловит «глупости» до того, как они уйдут в код.

При этом Сальваторе подчёркивает: огромная начальная спецификация — ключ ко всему остальному. Без неё невозможно было ни прогнать ревью каждой строки в sparsearray.c и t_array.c, ни решать, что переписывать, ни понимать, какой именно компромисс ты только что принял.

Что взять на заметку разработчику

1. Сначала спека, потом AI. Если задача системная — потратьте первый этап на ручное написание спецификации. AI может качественно её прокачать через диалог, но не сгенерировать с нуля.
2. Не идите на компромисс по архитектуре, если AI это закрывает. Громоздкая правильная реализация теперь под силу одному человеку. Если внутреннее представление кажется «не тем» — пересоберите его, пока спека ещё свежая в голове.
3. Ревью каждой строки. AI хорош в тестах и поверхностном «работает», но качество кода остаётся за вами. Без построчного чтения после того, как «всё работает», оптимизировать дизайн — на ощупь.
4. Чередуйте модели. Хотя бы две (например, GPT 5.x и Claude). Это не страховка от падений API, а способ увидеть проблему с разных углов.
5. Следите за тем, что под рукой. Сальваторе нашёл идею ARGREP не через roadmap, а через собственный сценарий: хранил Markdown в Array, понадобился полнотекстовый поиск.

Выводы

История Redis Array — короткий, но содержательный кейс того, как меняется планка инфраструктурного программирования с приходом AI-ассистентов. Не «AI пишет код», и даже не «AI делает программиста быстрее в 5 раз». А «AI убирает потолок сложности, который раньше задавался выгоранием и страхом ошибиться в дальнем углу системы».

Похожий тренд мы недавно разбирали со стороны GitHub: их CTO признал, что план по 10-кратному наращиванию мощностей пришлось переписывать в 30-кратный — потому что объём AI-сгенерированного кода вырос быстрее, чем планировали. Со стороны автора одиночного проекта это выглядит так же: новый этаж сложности достижим без новой команды.

Источник: Redis array type: short story of a long development — antirez.com.

Компилятор написан на Rust, насчитывает около 100 000 строк кода и может собирать Linux 6.9 для архитектур x86, ARM и RISC-V.

Как это вообще произошло

В эксперименте использовалась модель Claude Opus 4.6, запущенная в режиме так называемых agent teams. Это подход, при котором несколько экземпляров ИИ работают параллельно над одним репозиторием и сами решают, какие задачи брать дальше.

Всего в проекте одновременно работали 16 агентов, каждый из которых запускался в отдельном контейнере и синхронизировался через Git.

Чтобы агенты не мешали друг другу, они «блокировали» задачи с помощью файлов-локов — если один агент уже взялся за парсинг if, другой был вынужден выбрать другую часть компилятора.

Процесс длился почти две недели и включал около 2000 сессий Claude Code. Общая стоимость эксперимента составила примерно $20 000.

Что умеет получившийся компилятор

На выходе получился рабочий, хоть и экспериментальный инструмент:

• собирает Linux 6.9;
• компилирует крупные проекты вроде SQLite, Redis, FFmpeg и QEMU;
• проходит около 99% тестов из GCC torture test suite;
• способен скомпилировать и запустить DOOM — неофициальный, но показательный бенчмарк.

Важный момент: у ИИ не было доступа к интернету, то есть делалось в рамках имеющейся «базы знаний» модели.

Где начинаются ограничения

Несмотря на впечатляющий результат, компилятор далек от промышленного использования:

• нет собственного ассемблера и линковщика — они частично заимствуются у GCC;
• кодовая база нестабильна: новые изменения часто ломают старые части;
• 16-битный x86-код (нужный для загрузки Linux) реализован «читерски» — через вызов GCC.

Сами авторы также подчеркнули, что модель уперлась в потолок своих возможностей — дальнейшее развитие компилятора становится все менее предсказуемым.

Из-за накопившихся уязвимостей проект переходит на новый алгоритм — Counter Galois Onion (CGO). Он уже внедрен в Arti (реализацию Tor на Rust) и в классическую C-реализацию.

Почему tor1 небезопасен

Tor1 использует режим AES-CTR. Он достаточно быстрый, но одновременно с этим и уязвимый к ряду атак. Авторы выделяют три ключевые проблемы:

• Тегирование трафика (tagging attacks). Отсутствие hop-by-hop аутентификации делает поток ячеек изменяемым. Вмешавшись, атакующий может деанонимизировать пользователя.
• Нет мгновенной прямой секретности. Одни и те же ключи живут весь срок цепочки. Получив ключ, злоумышленник способен расшифровать все предыдущие данные.
• Слабая аутентификация. Подпись была всего 4 байта на SHA-1 — это 1 шанс из 4 млрд пройти незамеченным. Для криптографии — ничтожно мало.

Что меняет новый CGO

CGO решает проблемы комплексно. Алгоритм вводит две ключевых идеи:

1. Irreversible Update. Ключи обновляются при каждом новом сообщении и старые версии невозможно восстановить. Это дает мгновенную «совершенную прямую секретность».
2. Wide-block шифрование. Любая попытка изменить хотя бы байт приводит к полной порче расшифровки — атаки тегирования становятся бессмысленны.

Также MD4 заменен на полноценный 16-байтный аутентификатор.

Когда изменения доберутся до пользователей

Tor уже применил CGO в Arti и в реализации на C. Tor Browser, Tails и Orbot постепенно перейдут на новый метод автоматически — пользователю не надо ничего настраивать вручную.

Для большинства это будет тихое, но крайне важное обновление: впервые за долгие годы Tor получает серьезное усиление защиты на уровне базовой криптографии.

Если находка подтвердится, перед нами — одна из старейших копий легендарной операционной системы.

Как нашли ленту

Ленту обнаружил профессор Роберт Риччи во время уборки в школе вычислительной техники Университета Юты.

Она лежала в обычной коробке на пыльной полке — без особых отметок. После публикации фотографии находки, на нее обратили внимание историки и инженеры по сохранению ПО.

Чтобы не повредить артефакт, Риччи передал его в Computer History Museum в Калифорнии. И там, прямо сейчас, ленту осторожно побитово «снимают», не запуская на обычных магнитофонах. Это нужно для того, чтобы не стереть данные.

Почему это важно

Unix V4 — одна из первых версий, переписанных на языке C. Именно этот шаг сделал систему переносимой между разными машинами. И уже из этого решения выросли Linux, macOS и Android, а архитектура Unix до сих пор лежит в основе большинства современных ОС.

До последнего считалось, что оригинальная V4 утеряна — в архивах сохранились лишь обрывки кода и фрагменты мануалов.

Если лента окажется полной, это закроет огромный пробел в истории вычислительной техники.

Проблема «цифровой археологии»

Ленты 70-х часто страдают от деградации оксидного слоя и «осыпания» носителя. Иногда их приходится буквально запекать при низкой температуре, чтобы стабилизировать материал перед чтением.

Кроме того, формат данных может быть уникальным — в те годы каждый разработчик использовал свои схемы записи.

Почему Unix из Юты — особенный

В 1970-х Юта была одним из ключевых узлов ARPANET и первых университетов, получивших Unix по исследовательской лицензии Bell Labs. Местные студенты и инженеры активно модифицировали систему.

Именно из таких экспериментов, например, позже выросли BSD и многие современные утилиты.

Что дальше

Эксперты из Computer History Museum планируют оцифровать ленту и, при возможности, опубликовать исходники для исследователей.

Если восстановление удастся, это будет самое значимое возвращение утерянного программного кода за последние десятилетия — своеобразная «цифровая археология» уровня открытия древнего манускрипта.

Это означает, что для сборки системы контроля версий потребуется установленный компилятор Rust — как неотъемлемая часть инфраструктуры.

Что происходит

Предложение активно обсуждается в списке рассылки разработчиков Git. Идея заключается в поэтапной интеграции Rust, аналогично тому, как ранее был внедрен стандарт C99:

• На тестовом этапе Rust останется необязательным, но его использование будет поощряться.
• Начиная с Git 3.0, Rust может стать жесткой зависимостью, необходимой для сборки проекта.

Почему Rust?

Интеграция Rust началась в Git 2.49 (март 2025 года), где появились первые экспериментальные компоненты:

• libgit-sys — низкоуровневая обвязка над внутренними C-библиотеками Git.
• libgit — высокоуровневая библиотека для написания компонентов на Rust.

В июле 2025 года в проект был предложен Rust-патч для утилиты xdiff, который, по замерам, улучшает производительность на 5–19%. Именно тогда впервые прозвучала идея сделать Rust обязательным.

Но не все так просто

Мнения разработчиков Git разделились. Среди основных аргументов «против»:

• Ограниченная кросс-платформенность Rust — не все целевые платформы Git в полной мере поддерживаются компилятором rustc.
• Увеличение сложности сборки для пользователей и дистрибутивов.
• Опасения, что переход может исключить «редкие» платформы из числа официально поддерживаемых.

Сторонники же отмечают:

• Рост производительности.
• Безопасность и современный инструментарий, которые дает Rust.
• Возможность постепенного переписывания уязвимых и сложных компонентов Git с более надежным управлением памятью.

Что дальше

Пока решение не принято. Но вопрос об обязательной зависимости Rust будет решаться до релиза Git 3.0, который может состояться в 2026 году.

Ожидается, что сначала язык будет использоваться в опциональных частях, а затем его статус пересмотрят с учетом зрелости экосистемы и совместимости.

Обязательная поддержка Rust в Git станет важной вехой: Git всегда был проектом, ориентированным на C и минимальные внешние зависимости. Переход к Rust — это потенциальное изменение философии.

Причина — невозможность гарантировать безопасность через тестирование.

Тестировать безопасность невозможно. Нельзя понять, когда ты действительно закончил

Почему C больше не устраивает

На фоне усиления киберугроз, в NVIDIA начали пересматривать подходы к разработке и верификации ПО.

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

Что такое SPARK и как его внедрили

SPARK — это строго типизированный, безопасный для памяти подмножество языка Ada, предназначенный для написания кода, который можно формально верифицировать. Такие программы можно математически доказать на предмет корректности, отсутствия ошибок и уязвимостей — задолго до запуска.

Еще в 2018 году NVIDIA провела proof-of-concept: две низкоуровневые, чувствительные к безопасности C-программы были переписаны на SPARK за три месяца. Итоги оказались настолько успешными, что спустя несколько лет:

• в SPARK пишутся целые модули коммерческих продуктов NVIDIA;
• обучено более 50 разработчиков;
• верификация значительно упростила процессы аудита и укрепила доверие клиентов.

«Мы не просто запустили инструмент поиска багов — мы формально верифицировали этот код. Это сильно повышает доверие со стороны клиентов», — отмечается в кейсе.

Возражения скептиков развеялись

Переход с C на SPARK изначально вызывал сомнения внутри компании. Однако практический опыт показал:

• производительность не упала: «разницы с C не заметили», — признались разработчики;
• формальная верификация сократила затраты на аудиты;
• некоторые изначальные критики стали активными сторонниками подхода.

Что дальше

Хотя SPARK пока используется точечно, его уже применяют в чувствительных к безопасности частях — там, где традиционные языки и методы верификации не дают нужного уровня уверенности. NVIDIA делает ставку на переход от тестов к доказательствам.

Больше новостей — в нашем тг-канале «Представляешь»

Казалось бы, элементарная вещь — но даже опытные разработчики могут упустить полезные возможности языка, особенно если «учились Си» ещё во времена K&R и переходили к ANSI-C уже на лету.

В своём блоге он вспоминает, как на старых компьютерах int был не 32-битным, как сегодня, а 16-битным. На Radio Shack CoCo int вмещал значения до 65535, а на Commodore Amiga, возможно, уже был 32-битным. Именно из-за таких несостыковок переносимость кода между платформами становилась настоящим испытанием.

От самодельных типов к стандарту

Чтобы справиться с неопределенностью, разные разработчики создавали собственные типы: u_int32, I16, U32 и так далее. Позже появились стандартизированные stdint.h и limits.h, которые ввели чёткие типы (uint32_t, int16_t) и константы вроде INT_MAX и UINT_MAX.

Наш герой знал про эти макросы и успешно использовал их. Но, как выяснилось, он упустил одну вещь: stdint.h тоже содержит свои пределы — UINT32_MAX, INT64_MIN, INT8_MAX и десятки других. Эти макросы позволяют писать ещё более надёжный и переносимый код, особенно когда важно жёстко фиксировать размер чисел.

Код, который всегда работает

До недавнего времени программист вручную писал значения вроде 4294967295 для uint32_t — но теперь он просто использует UINT32_MAX. Это не только читаемо, но и работает на любой платформе, где uint32_t определён.

КОД

С signed-типами — аналогично: INT32_MAX, INT16_MIN и так далее. Стандарт Си делает всё это доступным уже давно — просто нужно об этом знать.

Урок: даже в Си есть чему удивляться

Автор оригинального материала признался: он просто не получил «меморандум» о появлении этих макросов в stdint.h. А ведь они могли сэкономить ему часы — если не годы — возни с ручным вводом чисел и багами на разных архитектурах.

Мораль проста: даже если ты 20 лет пишешь на Си — всегда найдётся что-то новое. И хорошо, когда язык даёт инструменты, которые делают код чище и безопаснее.

Это устройство с процессором PowerPC 7447B на 1.5 ГГц, 1 ГБ оперативной памяти и 32-битной системой. Тем не менее, ему удалось реализовать инференс модели Llama 2 (110M параметров) — без графических ускорителей и сторонних библиотек.

В основе проекта — llama2.c от Андрея Карпати, минималистичная реализация LLM на чистом C. Автор переработал код, оформив его в виде библиотеки с публичным API и поддержкой колбэков, чтобы упростить тестирование и интеграцию.

Оптимизации и ограничения

Для работы на PowerPC потребовались изменения:

• добавлены обертки для системных функций,
• устранены зависимости от exit,
• реализована поддержка big-endian (в отличие от little-endian в современных системах),
• улучшена обработка ошибок и выделение памяти.

Основной узкий момент — матричные операции. Именно они занимают большую часть времени при генерации текста. Чтобы ускорить выполнение, автор переписал критическую функцию с использованием SIMD-инструкций AltiVec, доступных в процессорах PowerPC.

Результаты

Для базовой оценки была использована модель TinyStories (110M). На сервере с процессором Intel Xeon inference шел со скоростью 6.91 токенов в секунду. На PowerBook G4 — 0.77 токена/сек.

С учетом возраста и ограничений устройства, результат выглядит убедительно. После внедрения SIMD-оптимизаций скорость увеличилась до 0.88 токена/сек.

Зачем всё это

Эксперимент показывает, что современные ИИ-модели могут быть адаптированы даже под устаревшее оборудование, если архитектура реализации достаточно прозрачна и эффективна. Это не только дань инженерному любопытству, но и практическая демонстрация гибкости минималистичных решений.

Сам автор отмечает, что на этом этапе проект завершен: возможности 32-битной системы ограничены, а запуск более крупных моделей упирается в нехватку адресуемой памяти.

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

В своём материале он показал, что даже этот простой пример скрывает множество технических деталей, которые обычно остаются за кадром.

Так, при компиляции, она превращается в исполняемый файл, полный символов и зависимостей.

Например, команда objdump -x hello показывает, что даже базовая программа содержит множество секций, таблиц символов и метаданных:

Попытка минимализма

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

Это требует непосредственного написания системных вызовов Linux. Например, вызов write можно реализовать напрямую:

Разбор структуры ELF-файла

Статья подробно объясняет структуру ELF (Executable and Linkable Format) — стандартного формата для Unix-систем.

Заголовки ELF, секции и сегменты взаимодействуют друг с другом для создания исполняемого файла.

Например, заголовок ELF содержит ссылки на таблицы символов и разделы, такие как .text (код программы) и .data (данные).

Линкер и оптимизация

Автор также разбирает использование кастомных скриптов линковки для создания минималистичных исполняемых файлов.

Например, с помощью линкера ld можно исключить ненужные зависимости и сократить размер программы.

Выводы

Как оказалось, даже простая программа «Hello, World!» скрывает сложность, связанную с взаимодействием компилятора, линкера и операционной системы.

Материал автора в очередной раз подчеркнул важность понимания базовых элементов программного обеспечения и их влияния на процесс выполнения программ.

Мы уже проводили батл в прошлых 2020, 2021 и 2022 годах: первые два раза в голосовании победил Python, а в прошлом году — C#.

Вот, кто поборется за звание лучшего языка в 2023 году:

Правила батла остаются прежними:

1. В батле участвует 16 языков программирования.
2. Ежедневно соревнуются две пары.
3. За любимый язык можно проголосовать в течение 24 часов.
4. Пары составляются рандомно, так что выбирайте язык, который субъективно нравится больше.
5. В финале мы определим тройку победителей.
6. Старт — 19 декабря, финал — 26 декабря.

Примечание Сохраните эту запись в закладки: сюда мы добавим ссылки на все раунды батла во время голосования.

1. Первый раунд
2. Второй раунд
3. Третий раунд
4. Четвёртый раунд
5. Пятый раунд
6. Шестой раунд
7. Полуфинал
8. Финал
9. Результаты

Также подпишитесь на тэг Лучший язык 2023. Тогда новые раунды батла появятся в вашей личной ленте, а вам будут приходить уведомления об их появлении.

Старт уже завтра — 19 декабря в 11:00 МСК. Следите, участвуйте, голосуйте!

В этой статье рассказываем, как бизнес в 1950 годах появлиял на развитие языков программирования, какие шаги проделал ALGOL перед тем, как превратился в язык Си, и как языки проделали долгий и витиеватый путь от упрощения к усложнению, и наоборот.

Как началась гонка языков программирования между Грейс Хоппер и Джоном Бэкусом

В 1953 году математик Грейс Хоппер работала в компании Remington Rand, под началом которой она когда-то выпустила первый в мире компилятор «A Compiler».

Хоппер уже была известным программистом, поэтому корпорация поставила перед ней новую задачу: облегчить бизнесменам, которые использовали компьютеры, работу с ЭВМ.

Хоппер решила, что проще всего будет научить бизнесменов программировать, но в Remington Rand ей отказали: это было бы слишком дорого и долго. И вообще, у бизнесменов нет времени учиться математике, разбирать перфокарты, и так далее. Тогда Грейс Хоппер поняла, что вместо того, чтобы заучивать математические формулы, лучшим способом будет использовать слова из английского языка, с помощью которых можно было бы программировать.

В Remington Rand снова были недовольны: мол, Грейс Хоппер снова выдумала слишком сложную систему, которая ещё и потребует больше компьютерных ресурсов. Однако профессор математики из Гарварда не сдалась, и в 1955 году представила прототип языка программирования FLOW-MATIC.

FLOW-MATIC представлял собой декларативный язык программирования, который разрабатывался для автоматизации бизнес-процессов. Для описания вычислений или обработки данных использовались ключевые слова, такие как “SUM” (сумма) или “COMPUTE” (вычисление). FLOW-MATIC также включал возможность работы с переменными данных и логическими условиями, что делало его гибким для разработки различных бизнес-приложений.

Обо всех новинках на рынке развивающихся ЭВМ программисты узнавали из ежемесячных профильных журналов, среди которых был “The Communications of the Association for Computing Machinery”. Работа Грейс Хоппер и её команды также не осталась незамеченной.

В это же время математик Джон Бэкус, который работал в IBM, написал руководству письмо, в котором предложил разработать совершенно другой язык программирования, полностью ориентированный на математические формулы. Дело в том, что сложные формулы было трудно перенести в код ассемблера без ошибок.

Надо отметить, что Бэкус тоже был известным математиком, который в начале 50-х создал интерпретатор для кода, поэтому предложение одобрили.

В итоге в конце 1954 года была составлена первая спецификация The IBM Mathematical Formula Translating System.

Тут началась гонка языков программирования. Хоппер пыталась сделать компьютеры более дружелюбными для бизнес-пользователей, а Бэкус ломал голову над тем, как сделать компьютеры более дружелюбными для математиков.

Появление ALGOL и его эволюция в язык BСPL

Примерно к 1958 году Association for Computing Machinery совместно с немецким Обществом прикладной математики и механики (Gesellschaft für Angewandte Mathematik und Mechanik) создала рабочую группу, которая должна была создать “универсальный” язык программирования.

В мае-июне 1958 года в Цюрихе был организован форум, на котором обсуждался вопрос о создании Международного алгоритмического языка или IAL, название которого со временем трансформировалось в ALGOrithmic Language, то есть ALGOL.

Как это касается героев нашей статьи? Джон Бэкус тоже был в команде ACM по разработке ALGOL, но в это же время он работал над другим языком программирования — FORTRAN. Грейс Хоппер, которую на форум ACM не позвали, в то время работала над COBOL. В общем, Бэкус и Хоппер, как и в ситуации с компилятором и интерпретатором, занимались схожими проблемами, хотя их пути снова не пересеклись.

Команде ACM удалось выпустить ALGOL, но у него было множество серьезных недостатков. Большинство из них исправили в ALGOL-60, который стал чем-то вроде колыбели для многих других языков программирования. По словам Тони Хоара, разработчика алгоритма «быстрой сортировки», ALGOL-60 был лучшим языком по сравнению со многими своими преемниками.

В начале 60-х годов в Кембридже и в Университетском колледже Лондона ALGOL-60 все же были недовольны. Ученые объединились и создали CPL – Combined Programming Language (или Cambridge Plus London, есть и такая версия).

В отличие от ALGOL-60, который был минималистичным и полагался на элегантный дизайн для решения сложных задач, CPL предоставлял больше инструментов для решения проблем. Во многом CPL заимствовал достоинства FORTRAN, COBOL и SNOBOL и интегрировал их в ALGOL.

Однако CPL требовала значительных вычислительных ресурсов, которые надо было постоянно поддерживать и расширять. Это значит, конечно, что для программирования на CPL надо было постоянно тратиться на дорогущее железо.

К 1967 году программистам это совсем надоело, поэтому Мартин Ричардс из Кембриджа предложил снова упростить CPL. Если в прошлый раз CPL был осложнённым языком ALGOL, то теперь Ричардс предложил выбросить как можно больше компонентов от него же.

Следите за руками: сперва Хоппер и Бэкус начали создавать простые языки программирования, потом на основе их разработок был создан язык посложнее, то есть ALGOL. Потом на основе ALGOL появился ещё один язык посложнее, а теперь снова появилась потребность в том, чтобы упростить разработку.

В общем, программистам снова нужен был простой язык, который был бы более basic. Так появился Basic Combined Programming Language.

Как язык программирования BCPL стал языком B

Basic Combined Programming Language или BCPL был прекрасен. На нём было удобно писать, код можно было легко переносить, а претензий к программам вовсе не было. Код BCPL учитывал основные типы архитектур ЭВМ того времени, поэтому он отлично подходил для множества компьютеров.

Вот Hello World на BCLP:

Всё испортила эволюция компьютеров. Сотрудник Bell Labs Кен Томпсон обнаружил, что BCPL с её ориентацией на машинные слова плохо подходит для грядущей волны компьютерных систем с байтовой адресацией.

К примеру, в его лаборатории стоял новенький компьютер PDP-11, и BCPL на нём работал плохо. Томпсон решил переделать BCPL, превратив его в BCPL-lite. От первоначального языка программирования осталась примерно четверть, поэтому и от его названия была отобрана только одна буква из четырёх — буква B из BCLP.

Язык B был вполне успешным: он был похож на BCPL, но вернул возможности ALGOL-60 по работе с типами данных. Томпсон хотел создать “семантику BCPL с большим количеством синтаксиса SMALGOL”.

Начиная с 1972 года, коллега Томпсона по имени Деннис Ритчи решил проапгрейдить B. Язык стал универсальнее, и теперь он подходил как для написания приложений, так и для написания системного кода.

Кроме того, новый язык на основе B учитывал разнообразие типов появляющихся компьютеров. Около 1974 года Ритчи закончил работу над языком, который был следующим этапом эволюции после B. Конечно же, он назвал его C.

Появление языков C и C++

Язык C быстро стал универсальным языком в разработке систем и во многих исследованиях в IT. Эту нишу он занимал очень, очень долго. Язык Си стал инструментом, который использовали и для обучения, и для создания очень сложного и производительного кода.

Си не менялся до тех пор, пока один датчанин по имени Бьерн Страуструп не принялся за написание докторской диссертации. В скандинавских странах широкой популярностью пользовался язык Simula, разработанный норвежцами. Страуструп решил объединить возможности Simula (в частности, наследование, сильную типизацию и инлайнинг) с языком Си.

Дело в том, что Simula был очень медленным языком, а BCPL была слишком сложной для написания высокоуровневых программ.

В рамках докторской диссертации Страуструп решил создать инструмент, который был бы производительным, но при этом обеспечивал абстракцию. Его первой разработкой стал C with Classes.

В 1982 году он решил доработать C with Classes, чтобы язык мог работать над проблемой распределенных вычислений. Так появился C++.

Изначально Cpp не был полноценным языком. Это был пакет препроцессоров для языка C. Первый публичный релиз 1985 года, Cfront 1.0, был довольно приличным, но чтобы пользоваться им, надо было быть экспертом в C, чтобы не сломать свой же код.

К 1987 году GCC 1.15.3 начал поддерживать C++, а в 1989 году появился Cfront 2.0, который был гораздо лучше первой версии пакета.

Тем временем, Международная конференция по стандартизации стала набирать популярность, и в 1990 году был создан комитет ANSI C++, а в 1991 году – комитет ISO C++. В итоге появились C++98/03, затем C++11, затем C++14, C++17, C++20, и так далее.

Заключение

Вся эта длинная история началась с того, что людям просто не хотелось учить новое. Эта потребность бизнеса в простом решении в середине прошлого века привела к тому, что величайшие математики века раз за разом совершенствовали языки программирования. В конечном итоге, это привело к появлению C++.

Сперва они создали простой язык, затем усложнили его, затем снова упростили, затем снова усложнили, затем снова упростили, немного усовершенствовали, и снова усложнили.

Сколько еще раз нам придется наблюдать этот процесс и во что превратится C++ в течение следующих пятидесяти лет?

В ответ Линус Торвальдс поделился своим мнением: bullshit — это сам Какурин, C++ — это ужасный язык, на котором кодеры генерируют, мягко говоря, «нечистоты», а программистов C++ вовсе не стоит допускать до Linux.

После откровенных оскорблений Торвальдс перешел к аргументам.

Позиция Линуса Торвальдса относительно C++

В первую очередь, Линус говорит, что использование C++ неизменно приводит программиста к плохим решениям вроде использования библиотек STL или Boost, которые считаются прекрасными.

Однако на деле, по мнению Линуса, они постоянно ломаются, отладка кода становится испытанием, а сам код нестабильный и не портируемый.

Также Торвальдс заявил, что код на C++ построен на абстракциях, которые не работают как следует. Программист может легко обнаружить, что использованная им абстракция неэффективна, и захочет заменить ее, но для этого ему потребуется переписать все приложение.

Если же программист захочет написать хорошее, эффективное и портируемое приложение на C++, он будет ограничен рамками, которые уже хорошо реализованы на языке Си.

Кроме того, использование Си страхует программистов от ошибок, и они не смогут «облажаться» на проекте, а сам язык учит кодеров разбираться в низкоуровневых проблемах. По версии Торвальдса, сплошные плюсы.

Линус признался, что в 1992 году они уже пытались использовать C++ для написания Linux. С тех пор, по его мнению, мало что изменилось.

Компиляторы C++ все так же не вызывают доверия, а обработка исключений в них вообще не работает.

Еще C++ скрывает потребление ресурсов, поэтому использовать его для написания ОС Линус считает невероятно глупой затеей. Зато объектно-ориентированный код можно написать на С без всяких проблем.

Позиция защиты C++

Линус думает, что ненавидит C++. Но, судя по его комментариям, он вообще не знает C++, а то, что он знает, давно устарело.

Ранние компиляторы C++ были довольно глючными. Они были не намного хуже, чем компиляторы C, но ошибки в них были разными. При этом компилятор C, который он использовал (gcc), тщательно тестировался на ядре Linux, поэтому он почти никогда не видел в нем ошибок. Зато в компиляторе C++ эти ошибки он мог найти с легкостью.

C++ был первым популярным объектно-ориентированным языком, а его ранние версии C++ были написаны на Smalltalk со странным синтаксисом. Поэтому ранний C++ работал плохо, и особенно плохо он работал в ядре Linux.

Похоже, что Линус сделал поспешные выводы, основанные на минимальном анализе. Когда он увидел, что C++ работает не так, как он ожидал, он просто отмахнулся от него, вместо того, чтобы изучить. К примеру, в C NULL может быть типобезопасным, а в C++ для этого нужно использовать nullptr, а не NULL.

С тем же успехом Линус Торвальдс мог бы заявить, что ненавидит язык суахили, потому что он его не знает.

Заключение

В целом, Линус Торвальдс прав, и для ядра Linux действительно лучше подойдет низкоуровневый язык Си, а не C++. Но в остальном вся его ненависть сводится к тому, что он попробовал использовать C++ практически на старте языка, и тот ему не понравился.

Кроме того, стоит помнить, что Линус говорит о C++ в контексте использования языка для написания ядра операционной системы. Этой же позиции придерживаются и другие авторы ОС. Ядра Windows, Linux, iOS, MacOS, FreeBSD написаны на языке Си.

А что о C++ думаете вы? Справедливы ли нападки Торвальдса?

Однако у Java есть и некоторые минусы, которые могут натолкнуть вас на мысль о переходе на другой язык программирования.

В этой статье разбираемся, зачем переходить с Java на С или С++, зачем учить именно С-языки и какие плюсы и минусы присущи С и С++ по сравнению с Java.

Зачем переходить на C/C++ после Java

За некоторыми исключениями C++ считается чем-то вроде надстройки Java, но это не значит, что при переходе с Java на C++ будет просто: вам нужно будет изучить новые концепции языка и новый синтаксис.

Основное преимущество C++ заключается в том, что он не обременяет новичка концепциями объектов. Также C++ лучше поддерживает более поздние классы, которые используются в написании операционных систем и построении компиляторов. Написание ОС в Java осложняется тем, что JVM сама по себе является подобием ОС.

Если вам нужно написать код, который управлял бы железом устройства, изучение байт-кода JVM не рекомендуется: он плохо переводится на язык ассемблера. Код Java “живет” в JVM, которая отрывает программу от железа.

Java присуща негибкость: например, код отличается многословным синтаксисом, который нелегко сократить. Код на Java, кажется, имеет другой стиль разработки, который поощряет крупные и сложные решения, тогда как более мелкие и простые были бы эффективнее.

C/C++, с другой стороны, ужасно беспорядочные языки, которые наполнены устаревшими функциями. Хуже того, из-за этого беспорядка можно выстрелить себе в ногу, написав отличный код, но не учтя нюансов его работы, о которых вы никогда и не слышали.

Однако код на C/C++ более гибкий, и как только вы его изучите, вы поймёте, что можете решить проблему множеством способов. В Java при этом обычно поощряется один способ решения задачи.

Кроме того, в процессе изучения C/C++ вы научитесь работе с указателями, стеком, производительностью, изучите процесс компиляции и системное программирование.

Резюмируя, вот причины, по которым вам стоит перейти с Java на C/C++:

1. Вам нужно написать программу, которая тесно взаимодействовала бы с железом.
2. Вы хотите изучить низкоуровневый язык программирования.
3. Вы хотите следить за последними обновлениями в языках программирования.
4. Вам хочется писать на “гибком” языке программирования, который предложил бы несколько решений проблемы.
5. Вы хотите писать лаконичный код.

Зачем учить С

Обычно С предлагают учить перед С++, потому что кажется, что сперва нужно изучить менее развитый язык и понять концепции низкого уровня вроде malloc и free. И, конечно, эта точка зрения имеет право на жизнь.

К примеру, при изучении С вы сможете понять общие принципы языка, не вдаваясь в сложные концепции вроде классов, объектов, наследования, полиморфизма, шаблонов, обработки исключений и ссылок. Сперва полезнее изучить основные элементы С.

Ещё один существенный плюс С — его низкоуровневость. Если вы собираетесь писать операционную систему или драйвера для устройств, если вы хотите разрабатывать мобильные приложения, стоит присмотреться к С, а не к С++, потому что первый язык существенно выигрывает в производительности и скорости.

То же касается и геймдева: если игра требует быстрых вычислений, С станет отличным инструментом.

Однако у пути от менее развитого языка к более развитому есть существенные минусы. Вы можете обнаружить, что многие выражения C — это худшая версия выражений C++.

C — это низкоуровневый язык, который будет подталкивать вас к использованию небезопасных абстракций низкого уровня. Если вы сможете соблюдать типовую безопасность, проблем не возникнет.

Также способ управления памятью в C сильно отличается от C++, даже несмотря на то, что он построен на низкоуровневых абстракциях. Как ни странно, проще понять управление памятью через конструкции std::move() и std::unique_ptr в С++, чем malloc/free в C. Ещё один нюанс низкоуровневого С — сложность массивов.

Также в C++ есть выражения, которые были заимствованы из более современных языков и которых нет в C.

Оптимальный вариант — начать обучение с C++, а затем немного поработать с C, чтобы понять нюансы работы низкоуровневого языка.

Плюсы в пользу C после Java

• C — относительно простой язык с меньшим количеством функций, чем в C++.
• Изучение C углубит понимание концепций низкоуровневого программирования, таких как управление памятью и указатели.
• Код C легче переносить на разные платформы.

Минусы изучения C после Java

• В С меньше принципов ООП. C — это процедурный язык, и в нем не так сильно используется объектно-ориентированное программирование (ООП), как в Java или C++.
• В языке C отсутствуют современные функции и библиотеки, аналогичные тем, что уже есть в Java и C++.

Зачем учить С++

C++ — это язык, который лучше всего для жесткого контроля над управлением памятью. Также здесь играет огромную роль производительность программ.

С++ отлично подойдёт для высокопроизводительных вычислений, при которых вы не можете позволить себе расходы на память, но вам нужно, чтобы все работало как можно быстрее. C++ лучше подходит для высокопроизводительных численных вычислений, чем Java в целом. При этом учтите, что кривая обучения C++ очень большая.

Java, с другой стороны, не зависит от платформы и имеет большую поддержку библиотек (синтаксический анализ XML и т. д.). Java — это интерпретируемый язык, с которым вам не нужно беспокоиться об управлении памятью.

Недостатком Java является относительно плохая настройка производительности. В Java нет особого контроля над распределением памяти, и часто возникает нехватка высокопроизводительных числовых пакетов.

Что касается синтаксиса, в Java код очень подробный: всё должно быть классом, и каждый класс должен находиться в отдельном файле, и так далее. Однако и синтаксис C++ тоже непрост в изучении, так может быть препятствием в переходу с одного языка на другой.

Плюсы в пользу C++ после Java

• Как и Java, C++ является объектно-ориентированным и поддерживает классы, объекты и наследование.
• C++ предлагает более широкий набор функций, включая низкоуровневые манипуляции с памятью, шаблоны и стандартную библиотеку шаблонов (STL).
• C++ широко используется в разработке игр, системном программировании и приложениях, где производительность критична.

Минусы изучения C++ после Java

• C++ может быть сложнее в изучении из-за обширного набора функций.
• Хотя C++ предлагает контроль над управлением памятью, это также может привести к увеличению количества ошибок.

Заключение

Эта статья была написана на основе советов опытных программистов, которые больше 10 лет кодят на Java и С-языках. Надеемся, материал получился исчерпывающим и помог вам решить, стоит ли переходить с Java на С и С++.

Приглашаем вас присоединиться к дискуссии. Какие аргументы в пользу С/С++ мы забыли упомянуть? Или, может быть, есть и другие языки, которые закрывают проблемы Java, но на которые перейти было бы удобнее, чем на С-языки? Напишите в комментариях! 🙂

Стандарт был создан для того, чтобы повысить безопасность и надёжность кода в том случае, когда от его качества зависит жизнь человека. К примеру, MISRA используют в автомобильной отрасли.

К примеру, представьте, что ваш автомобиль из-за программной ошибки не позвонил в службу спасения. Или самолёт вдруг отказался опустить шасси. Или рентген взял и облучил вас высокой долей радиации. Или робот-хирург отказался работать посреди операции.

Конечно, эти примеры — донельзя утрированные, но столкнуться с ними в реальной жизни не хотелось бы никому. Именно жёсткий стандарт MISRA позволяет исключить возможность ошибки, которая может стоить жизни.

MISRA C определяет правила, которым разработчикам следует следовать при написании кода. Каждый год количество правил, по своей сути — запретов, только растёт:

• В MISRA-C:1998 указаны 127 правил: 93 обязательных и 34 рекомендательных.
• В MISRA-C:2004 указано 141 правило: 121 обязательное и 20 рекомендательных.
• В MISRA-C:2012 указаны 143 правила и 16 директив.

Они включают рекомендации по оформлению, по использованию конструкций языка, предупреждают о потенциальных проблемах вроде неопределенного поведения или возможности ошибок.

Как появился MISRA

Стандарт MISRA был разработан ассоциацией MISRA (Motor Industry Software Reliability Association) в 1994 году в Великобритании. Изначальная цель стандарта — повысить безопасность и надежность ПО для автомобилей.

В начале 1990-х годов количество электроники в автомобилях неуклонно росло. Стало очевидно, что некачественный код может быть опасен для пассажира: к примеру, ошибка ПО во время движения может стоить водителю жизни. Чтобы обезопасить пассажиров, и была создана ассоциация MISRA.

Первый выпущенный стандарт назывался “MISRA Guidelines for the Use of C in Vehicle-Based Software”. Его опубликовали в 1994 году. Он определил правила для использования языка Cи в автомобильном ПО.

Помимо общих правил вроде оформления кода, первый стандарт включал в себя:

1. Правила для управления типами данных, которые запрещали преобразование типов.
2. Рекомендации для обработки исключительных ситуаций (exceptions). Рекомендации по использованию операторов try-catch, исключений и т.д.
3. Запрет непортативных (non-portable) функций и конструкций, которые могут привести к неправильному поведению или ошибкам при переносе кода на другие платформы или компиляторы.
4. Рекомендации и требования к валидации кода и процессу разработки.

В последующие годы стандарт обновлялся и дополнялся. В 2004 году был выпущен стандарт “MISRA C:2004”, а в 2012 году – стандарт “MISRA C:2012”.

В 2023 году стандарт снова обновился

Где используется MISRA

Сегодня стандарт используют почти во всём транспорте — в автомобильной и авиационной отраслях —, в медицине и промышленности. Вот несколько компаний, которые применяют MISRA в разработке ПО:

1. Автомобильная промышленность: BMW, Ford, General Motors, Honda, Toyota и Volkswagen.
2. Авиационная промышленность: Airbus и Boeing.
3. Медицинская техника: Siemens Healthineers, Philips Healthcare и Medtronic.
4. Промышленные системы: Schneider Electric и Rockwell Automation.

Что запрещено в MISRA

Вот несколько примеров того, что запрещено в стандарте MISRA:

1. Фрагменты кода не должны быть закомментированы.
2. Базовые типы char, int, short, long, float и double не должны использоваться.
3. Операнды логических операторов && или || должны быть первичными выражениями.
4. Оператор goto не должен использоваться.
5. Заголовочный файл и функция setlocale не должны использоваться.

К примеру, вместо char, int, short, long, float и double нужно использовать директиву typedef.

Неправильный код:

Правильный код:

Операнды && и || должны быть одиночными переменными, константами или выражениями в скобках.

Неправильный код:

Правильный код:

С полным списком правил на русском языке можно ознакомиться по этой ссылке.

Как проверять код на соответствие MISRA

На рынке есть несколько анализаторов кода, которые проверяют соответствие стандарту MISRA.

1. PC-lint/FlexeLint — один из самых популярных инструментов статического анализа для языка C и C++. PC-lint/FlexeLint поддерживает проверку соответствия нескольким версиям стандарта MISRA C, включая MISRA C:1999, MISRA C:2004 и MISRA C:2012.
2. Polyspace — анализатор от MathWorks также поддерживает проверку соответствия стандарту MISRA C. Он помогает отслеживать проблемы вроде неопределенного поведения или использования небезопасных функций.
3. Klocwork — ещё один популярный инструмент статического анализа, который поддерживает проверку соответствия стандарту MISRA C.
4. Cppcheck — бесплатный и открытый инструмент статического анализа для C и C++. Изначально он не настроен на проверку соответствия стандарту MISRA, но Cppcheck помогает обнаружить некоторые нарушения.

Также есть пара компиляторов.

1. IAR Embedded Workbench — один из наиболее известных компиляторов, который предоставляет мощный статический анализатор для поиска нарушения правил MISRA и предлагает решения для их исправления.
2. MULTI IDE — интегрированная среда разработки (IDE) с компилятором, поддерживающим стандарт MISRA C. MULTI IDE включает в себя инструменты статического анализа, покрывающие правила MISRA и помогающие в обнаружении потенциальных ошибок.

Заключение

В заключение, стандарт MISRA C — важный инструмент для повышения качества и безопасности кода, который включает рекомендации и правила для написания надежного и поддерживаемого ПО.

Но стоит отметить, что соблюдение стандарта не всегда обязательно и зависит от требований проекта. Некоторые компании выбирают свой набор правил, адаптированных под их цели и реалии разработки.

Соблюдение стандарта MISRA C — это только один из инструментов при разработке безопасного ПО. Он должен быть использован вместе с другими методологиями и практиками вроде тестирования или обзора кода.

Надеюсь, статья оказалась интересной и полезной. Если вы работаете, к примеру, в разработке ПО для автомобилей, расскажите в комментариях, используете ли вы MISRA в работе. Может быть, есть и другие стандарты, которые на практике популярнее MISRA?

Введение

В современной разработке сложно представить себе серьезный проект, в котором не использовались бы практики CI/CD, а код не был бы покрыт юнит-тестами, однако при создании прошивок для микроконтроллеров далеко не каждая команда уделяет время настройке и поддержке этих процессов. При работе над одним из медицинских приборов мы обнаружили, что имеющиеся юнит-тесты покрывают только те части кода, которые отвечают за логику и программные вычисления, но совсем не затрагивают тестирование аппаратных функций. Эта статья про то, почему нужно обязательно тестировать вызовы к HW, почему пришлось менять фреймворк юнит-тестирования и как удалось упростить процесс перехода.

Зачем тестировать аппаратные функции?

Ответ на этот вопрос очень простой – затем же, зачем и неаппаратные, то есть, чтобы быть уверенным, что код работает именно так, как ожидается. Некоторые разработчики попадают в ловушку, предполагая, что если используются документированные SDK API, то можно целиком на них положиться и не перепроверять их работу. Однако представим себе разработку устройства на стадии подготовки прототипа. В любой момент может быть принято решение об изменении версии SDK или микроконтроллера, и в этом случае точно придется перепроверять работу аппаратных функций. Такие миграции возможны и при разработке очередной версии уже готового устройства, когда кодовая база успела значительно разрастись. А если продукт уже вышел в серийное производство, то понадобится проверка каждого устройства в заводских условиях. Для этого пишутся специальные тестовые прошивки, базой для которых легко может стать набор юнит-тестов для аппаратных функций.

Еще одна потенциальная проблема – запуск юнит-тестов на ПК недостаточен для проверки правильности вычислений. Из-за различий в аппаратной архитектуре самые обычные операции, например, арифметика чисел с плавающей точкой, могут давать разные результаты.

Ориентируясь на эти тезисы, мы занялись исправлением ситуации на проекте.

Выбираем фреймворк

На проекте на тот момент уже использовался популярный фреймворк GoogleTest для юнит-тестирования кода на С++. О его преимуществах говорить не будем, их много, и статья не о них. В нашем случае были важнее его недостатки, а именно – размер собранной библиотеки, который «съедал» солидный кусок из наших скромных 256KB.

Можно было, конечно, пропатчить код, оставив только используемые куски и сократив, таким образом, размер библиотеки, но это скорее походило на то, что мы используем неподходящий инструмент, чем на хорошее решение. Тем более, что был найден другой, гораздо более простой и легковесный фреймворк Unity (нет, никакого отношения к геймдеву не имеет), состоящий из пары заголовочных файлов и одного С-файла (что будет преимуществом, если проект написан на чистом С). Так как каких-то сложных тестовых сценариев нам писать не требовалось, то для тестирования аппаратных функций мы решили выбрать именно его.

На этой стадии получалось, что мы используем Unity для SDK API, и GoogleTest для всего остального. Вариант, в целом, рабочий, и в какой-то момент мы даже думали остановиться на нем несмотря на то, что иметь в проекте разные фреймворки для, по сути, одной задачи, это явно перебор. Но переводить уже имеющуюся базу тестов на новый фреймворк никто не горел желанием. Однако вскоре этот вопрос поднялся снова – часть тестов была направлена на проверку корректности вычислений, и требовала дублирования тестов на обоих фреймворках. А это уже было неприемлемо. Пришлось лезть внутрь исходников GoogleTest и смотреть на реализацию используемых тестовых макросов. Довольно быстро стало ясно, что можно написать собственный преобразователь GoogleTest => Unity, который позволит оставить код имеющихся тестов неизменным.

Пишем gtest2unity.h

В целом, идея довольно простая – переопределить макросы старого фреймворка собственными, которые используют макросы нового. В этом случае будет достаточно подменить заголовочный файл, не меняя ни строчки кода в тестах.

Начинаем с простого: устанавливаем соответствия между макросами проверки:

Что кроется за этими макросами нам не очень интересно, т.к. передаваемые параметры совпадают, и по имени можно определить, что проверки выполняются одинаковые. Оба фреймворка обладают внушительным арсеналом различных проверок, и вполне вероятно, что некоторым не найдется аналога, но для обычных юнит-тестов такой проблемы не возникает.

Теперь переходим к чуть более сложной части. Что еще используется в имеющихся тестах, связанное с GoogleTest?

Что ж, тут тоже очевидно, что нужен собственный класс testing::Test, от которого мы сможем наследоваться подобным образом.

Теперь переходим к последней части, зависимой от GoogleTest:

Здесь уже приходится обращаться к исходному коду GoogleTest, потому что догадаться, что скрыто за макросом TEST_F, довольно сложно (заинтересованным рекомендую обратиться к гитхабу проекта и изучить макрос GTEST_TEST_ в файле gtest-internal.h). Оказалось, что за TEST_F спрятано довольно много кода, большая часть из которого нам не нужна. Главные пункты, которые нам пришлось адаптировать:

– каждый тест-кейс – отдельный класс, унаследованный от нашего PumpDriverTests;

– тело тест-кейса – реализация приватной функции этого класса;

– нужна функция, которая создаст экземпляр этого класса, а затем последовательно вызовет его методы.

Сначала определим пару макросов для удобства, чтобы легко получать уникальные имена для наших классов и функций:

А затем реализуем описанные пункты:

Вот мы и получили рабочий вариант gtest2unity.h. Теперь для перевода файла с GoogleTest на Unity достаточно простого:

Ну и, конечно, добавить файлы Unity в систему сборки (например, в CMakeLists.txt). Ошибок компиляции больше нет, и наша работа закончена… или нет? Скомпилировать код без ошибок — это, конечно, хорошо, но сами тесты еще и запустить надо. GoogleTest определяет необходимые методы по умолчанию, но в Unity нужно все делать руками. Программисты, как известно, не очень любят ручную работу, поэтому мы решили написать простой генератор кода запуска тестов.

Генерируем test_runner.cpp

Запустить тесты с помощью Unity не сложно:

Над генератором долго не думаем – выбираем Python и вперед! Хардкодим подключение заголовочных файлов и части с UNITY_BEGIN и UNITY_END в локальные строки. Дальше парсим исходники, но и тут все довольно тривиально – находим макрос TEST_F в коде, вытаскиваем его параметры и записываем их в макрос EXTERN_TEST_F_NAME дважды – первый раз перед main() вместе с extern объявлением (даем понять, что сама функция находится в другом файле), второй уже внутри RUN_TEST, чтобы, соответственно, запустить сам тест.

Собрав информацию обо всех тест-кейсах, генерируем итоговый файл (который также нужно включить в систему сборки). Теперь и компиляция, и линковка, и запуск – все готово к тому, чтобы наши тесты падали при неудачных изменениях кода.

Заключение

В заключение хочется сказать, что мы ни в коем случае не рекомендуем использовать подобные трюки без крайней необходимости. В нашем случае достаточно было принять во внимание необходимость тестировать SDK API и с самого начала выбрать подходящий фреймворк юнит-тестирования. Однако мы редко встречаемся с идеальными условиями, поэтому стоит иметь ввиду, что иногда можно исправить ситуацию и с таким подходом.

Несомненно, приведенный код далек от идеала (а тот, который не показан, тем более), но для нашей ситуации его оказалось достаточно, и мы смогли продолжить работу над проектом, теперь уже покрывая тестами весь код.

Напомним, что индекс TIOBE оценивает популярность языков программирования, основываясь на поисковых запросах, которые содержат тот или иной язык. Для формирования индекса используются такие ресурсы, как Google, YouTube, Amazon, Wikipedia, Yahoo!, Bing и Baidu.

В 2023 году популярность языков изменилась. Какие языки потеряли популярность, а какие — нет, рассказали в этой статье.

1. Python, C и C++ соревнуются за звание лучшего языка
2. Пара слов о других языках
3. Выводы

Python, C и C++ соревнуются за звание лучшего языка

Именно таковы результаты по состоянию на конец декабря — двадцать языков программирования с наибольшей рыночной долей по версии TIOBE:

Ещё в прошлом году Java уверенно держалась в тройке, но теперь уступила своё место «плюсам». Любопытно, что в последний раз C++ становился лидером рейтинга TIOBE в далёком 2003 году, и это впервые, когда данный язык программирования обошёл Java по поисковым запросам. При этом Java входила в топ-3 свыше двадцати лет, начиная с 2001.

Уже в следующем месяце мы узнаем имя победителя. Каждый из лидирующей тройки уже занимал первое место по итогам года:

1. C++ — 1 раз (2003).
2. C — 3 раза (2008, 2017, 2019).
3. Python — 5 раз (2007, 2010, 2018, 2020, 2021).

Пара слов о других языках

Помимо прочего, мы видим, как Kotlin и Julia приближаются к топ-20, JavaScript держится в семёрке, а PHP вырывается в десятку, тогда как в прошлом году занял 12-е место.

Интересно, что Go поднялся аж на 7 позиций и теперь занял 12-е место рейтинга. Стоит отметить, что по версии GitHub за третий квартал 2022 Golang также находится на четвёртом месте по популярности, обогнав при этом PHP, C, C#, Ruby, TypeScript и JavaScript. Тенденция налицо:

На 18-е место рейтинга TIOBE вернулся Perl. Rust удерживает 20 позицию. Что касается Delphi, то он всю осень прыгал туда-сюда:

• сентябрь — 13 место (1.09%);
• октябрь — 18 место (0.85%);
• ноябрь — 14 место (1.08%).

В декабре же язык опустился на 16 место (0.85%), что соответствует результатам декабря прошлого года.

Выводы

Разумеется, рейтинг языков программирования 2022 TIOBE сложно назвать объективным, так как он рассматривает лишь один аспект — популярность ЯП в поисковых запросах пользователей. Он не отражает реальный рыночный спрос или количество написанного кода, как это делает GitHub в своих отчётах на основе проектов.

Тем не менее, индекс TIOBE можно использовать, чтобы проверить, актуальны ли ваши навыки, или принять решение о том, на какой язык программирования можно перейти или какой следует использовать при написании новой программы.

• Pascal и Python;
• C# и C.

Четвёртый раунд завершился победой TypeScript над JavaScript и Java над Rust. При этом TypeScript вырвался вперёд с преимуществом всего лишь в 4%.

Результаты прошлого раунда можно посмотреть здесь.

Подпишитесь на тег Лучший язык 2022 и следите за обновлениями в личной ленте, чтобы не пропустить новые раунды битвы.

Голосование по пятому раунду продлится до 18 декабря 2022 года. Опросы будут закрыты в 11:00 по МСК.

Результаты можно посмотреть здесь. Подпишитесь на тэг Лучший язык 2022 и следите за новыми раундами в личной ленте.

Сегодня в схватке столкнутся:

• Go и Python;
• Assembler и C.

Голосование по этим языкам программирования продлится до 15 декабря 2022 года. Опросы будут закрыты в 11:00 по МСК.

Правила батла по-прежнему просты:

1. В батле участвует 16 языков программирования.
2. Ежедневно соревнуются две пары.
3. За любимый язык можно проголосовать в течение 24 часов.
4. Пары составляются рандомно, так что выбирайте язык, который субъективно нравится больше.
5. В финале мы определим тройку победителей.
6. Старт — 13 декабря, финал — 20 декабря.

Примечание Забирайте эту запись в закладки, ведь именно в неё будут добавляться ссылки на последующие этапы голосования.

• Этап 1
• Этап 2
• Этап 3
• Этап 4
• Этап 5
• Этап 6
• Полуфинал
• Финал
• Результаты

Турнирная таблица:

Старт уже завтра — 13 декабря в 11:00 МСК. Следите, участвуйте, голосуйте!

Конкуренция становится всё жёстче, и в пятом раунде столкнутся:

• C vs. Java
• TypeScript vs. Go

Выбирайте язык, который вам по душе. Голосование в пятом раунде завершится 19 декабря 2021 года в 11:00 по Москве.

• C vs. PHP
• TypeScript vs. Assembler

Выбирайте любимый язык, исходя из личных симпатий. Голосование завершится 15 декабря 2021 года в 11:00 по Москве.

Ознакомиться с анонсом можно здесь.

Но давайте отвлечёмся от официальной статистики и узнаем, какие языки предпочитаете именно вы! Завтра стартует баттл языков программирования 2021. Правила просты:

1. Всего участвует 16 языков программирования.
2. Каждый день соревнуются две пары.
3. На возможность проголосовать за любимый язык отводится 24 часа.
4. Пары составляются рандомно.
5. Выбирайте тот язык, который субъективно нравится вам больше.
6. В финале мы определим победителей — языки которые заняли первое, второе и третье место.
7. Старт — 14 декабря, финал — 21 декабря.

Так выглядит изначальная турнирная таблица:

А вот как мы выбирали лучший язык программирования в прошлом году.

Подписывайтесь на уведомления на сайте, чтобы быть в курсе лидеров и новых голосований.

Результаты баттла можно посмотреть по ссылке.

Но это неважно. Важен пожар внутри тебя. Я бы хотел рассказать тебе историю моего необычного развития в IT, и то, куда меня ведёт пожар, горящий внутри меня. Я бы хотел рассказать тебе, на какие грабли я наступал, какие инструменты выбирал и какие уроки выучил на этом необычном и трудном пути.

Программирование для меня — просто хобби, которое я считаю одной из главных частей своей жизни. Сейчас я разрабатываю как для себя, так и для других, крошечную свободную программу для шифрования файлов, которой пользуюсь сам просто от того, что меня не устраивают все остальные.

Первые трояны

Первый компьютер мне купили в 2007 году, когда я учился в 8 классе. Я обожаю компьютерные игры и сейчас в них тоже играю. Первыми же моими играми были Painkiller и S.T.A.L.K.E.R. Но ещё мне было интересно, как работает компьютер, что он может и чего не может.

Я мог бы начать изучение операционных систем и языка программирования Pascal, как все нормальные школьники, но меня слишком вдохновляли истории взломов, совершенных такими звездами компьютерного андеграунда, как Кевин Митник, Адриан Ламо, Джонатан Джеймс и т.д. В их руках я видел почти безграничную, свирепую, непобедимую власть, которую они обрели лишь терпением, желанием и опытом. Я считал их полубогами и хотел быть подобным им. Я был восхищен тем, как простые люди могут нажать пару клавиш и обрушить что-нибудь, да так, что мир вздрогнет.

В один из дней моей юности я открыл Internet Explorer, зашёл на Яндекс и ввел самый глупый запрос: «как создать вирус».

В интернете того времени была масса инструкций, следуя которым можно было создать почти всё, начиная от троянов и заканчивая бестелесными полиморфными сетевыми червями, вроде Code Red или SQL Slammer. После прочтения массы сомнительных и околокриминальных источников с подозрительной рекламой эротического и мошеннического содержания я решил начать с написания .bat троянов, потому что это было легче всего.

Интерпретатор командной строки Windows XP, которой я тогда пользовался, позволял считывать команды прямо из файлов с расширением .bat. Я написал несколько троянов, один из которых прописывал себя в автозагрузку операционной системы и постоянно перезагружал компьютер. Я казался себе гуру, суперхакером, чуть ли не вершителем судеб, и тот огонь, вспыхнувший во мне от понимания того, на что я способен, не погас до сих пор. Я понял, что создание программы для компьютера — это не спорт, где нужны годы тренировок, и не искусство, требующее вдохновения и многолетнего опыта.

Если архитектор везде натыкается на материальные преграды вроде стоимости строительных материалов, то создатель программ — только на ограниченность своего ума, не считая стоимости компьютера. Смог я — сможет любой. Предела нет.

Позже я узнал про языки программирования, какими они бывают и зачем используются. Я узнал, что существует целый зоопарк операционных систем, и Windows XP — только одна из них. Я прочитал, что такое троян, червь, вирус, исходный код, дизассемблер, firewall, эксплойт, ФСБ, обыск и т.д. Со временем что-то во мне изменилось и я задумался, а смогу ли я создать что-нибудь по-настоящему полезное. Скачав первую попавшуюся пиратскую версию среды быстрой разработки приложений Delphi 7, о которой я узнал на одном из тех нехороших сайтов, я начал пробовать писать программы.

Первая программа

Первой разработанной мной программой была, насколько я помню, консольная программа для шифрования файла по паролю. Она открывала файл на чтение/запись, из которого читались данные, ксорились с паролем и записывались обратно в файл. Программа была написана так, что её исходный код лучше не видеть никому и никогда, чтобы просто не стать седым. Вот пример кода, который там реально был:

Уже и не помню, сколько файлов я испортил, пытаясь довести программу до ума. В итоге xor (сложение по модулю два) был выброшен на свалку, а выбран был алгоритм шифрования DES. Но со временем программа стала настолько сложной, что я уже сам не мог сказать, что и как в ней работает. И это в моей программе! Но меня ожидал хороший итог.

Хороший, потому что я понял свою ошибку — я не прочитал, как не надо делать, потому что это просто не пришло в голову. Мне даже не было дела до того, что до меня такие идиотские ошибки уже делали тысячи и тысячи людей! Я был невероятно некомпетентен!

Излазив сотни сайтов, я узнал про алгоритмы шифрования, какими они бывают, что такое режим шифрования и чем собственно плохи алгоритм DES и режим ECB (режим электронной кодовой книги), что такое перебор пароля, перебор ключа, криптоанализ, USA NSA и т.д. Но информации всё равно было мало, и мало настолько, что я был зол.

Как это так? В мире полно криптографических программ, а как их правильно разрабатывать, на форумах никто не знает? Да не может такого быть, думал я. Как оказалось, ещё как может.

Первый взлом программы

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

Я начал понемногу учить язык ассемблера для процессора x86, с которым познакомился благодаря отладчику уровня пользователя OllyDbg и дизассемблеру IDA Pro, который использовал в своей книге Крис. Всё, разумеется, было пиратским: и Windows XP, и IDA Pro, и всё остальное. Мне было неловко от того, что другие умеют делать из лицензионных программ пиратские, а я не умею. Я думал, что Кевин Митник уж точно знает, как взламывать программы, и захотел уметь так же.

Первый crackme (программа, созданная специально, чтобы быть взломанной) я взломал где-то за один час. Потом я взломал ещё один crackme, и ещё один, и ещё. Так я дошёл до того, что теперь мог редактировать собственноручно разработанные программы, к чему успешно перешёл. С помощью пиратской версии программы WinHex я редактировал свои программы и смотрел, что будет. Я менял значения констант, команду ADD (сложение) на команду SUB (вычитание), превращал циклы с условием в бесконечные циклы, а условные переходы JE (перейти, если равенство) в безусловные JMP.

Когда я перешёл от взломов к программированию на языке ассемблера, я написал программу, которая меняла команду ADD на SUB прямо во время исполнения, а позже процессор выполнял изменённые команды. Я понял, что теперь могу написать любую программу. Чтобы узнать, что делает такая программа, её было мало прочитать, её нужно было именно запустить. Так я открыл для себя трассировку программ (выполнение программы по одной команде).

Это было волшебно! Я могу, и могу такое! Ай да я, ай да мамин суперхакер, думал я.

Позже, поверив в себя, расправив плечи и надев чёрные очки, я начал творить то, что могло стоить мне свободы. Я решил перейти на сетевой уровень IT, но используя для этого не учебники информатики, а статьи и книги того же Криса Касперски. Я узнал, что существуют протоколы связи программ друг с другом, такие как HTTP, FTP, SMTP, POP3, как взламывают компьютеры по сети, что такое переполнение буфера в стеке с перезаписью адреса возврата, что такое «куча», DDoS атака и т.д.

На всё тех же сомнительных сайтах с нехорошей рекламой я многое прочёл про сетевые взломы, эксплойты, программы для перебора паролей, уязвимости и т.д. Я думал, что вот-вот взломаю весь мир и поставлю на колени плачущего директора ЦРУ. Я думал.

В процессе прочтения и попутного обучения огонёк во мне снова вспыхнул. Я снова пошёл по темной дорожке старых, восхищавших меня в самом начале пути полузаконных людей. В ночь с субботы на воскресенье, когда я пытался подобрать пароль к одному из FTP-серверов с помощью скачанной из интернета программы для перебора паролей, даже не зная, в какой стране находится сервер и зачем мне вообще к нему доступ, на домашний телефон позвонил неизвестный. Голос в трубке, искажённый ужасными помехами, спросил:

— Здравствуйте, вы дома пользуетесь интернетом?

— Ээээ… Да. А вы от какого-то провайдера звоните? — спросил я, и посмотрел на настенные часы, которые показывали 04:30 утра.

— Ээээ… Нет, — ответил голос в трубке и мы оба замолчали. Я первый раз в жизни услышал то, что теперь зову «ехидным молчанием», которое ужасно меня напугало! Мне показалось, что бетонные стены квартиры начали сжимать меня! Вдруг я понял, что рекламировать свои услуги ни один провайдер в выходной день, тем более в половине пятого утра, не будет. После ехидного молчания со стороны собеседника я повесил трубку. Спустя два часа я уже ехал в деревню к бабушке на первой же электричке, пытаясь предугадать, какой же срок мне грозит.

Всё обошлось, но такого опыта я не пожелаю и врагу. Я понял, что есть люди гораздо умнее меня и отрезвлять умы они умеют ещё как. Простым звонком в четыре утра. И да, я не хочу знать, кто мне звонил.

Разработка собственных программ

Будучи испуганным, отрезвлённым и просветлённым, я быстро свернул обратно на светлую дорожку, начав думать, чего же мне ещё надо.

— Что я могу? О, точно. Мне нужна своя база данных, как в фильме про агентов ЦРУ.

Сказано – сделано.

Я написал её где-то за неделю, и да, я знаю, дизайнер из меня так себе. Программе нужно было название, данное в какой-нибудь крутой корпорации, и я придумал её — Plexus. Это не база данных, а система управления базой данных (СУБД), работающая с файлами Microsoft Access, поддерживающая шифрование AES-KSM-256, хеширование MD5 и SHA-1, смену пароля пользователя перешифрованием ключа шифрования записей в базе данных, смену изображения, уничтожение данных на диске и поиск по маске.

Режим шифрования KSM я придумал сам: это тот же самый режим ECB, в котором в качестве ключа шифрования следующего блока данных используется hash (контрольная сумма) ключа шифрования предыдущего блока. Программа устанавливалась на компьютер простым копированием файлов из архива, а мне хотелось чего-то настоящего, ТруЪ, и я написал для неё установщик. Позже, когда всё было готово, я вспомнил, что забыл записать «лицензионный» ключ для единственного установщика моей же программы, что заставило меня написать keygen.

Да, я написал генератор «лицензионных» ключей для собственной программы! А откуда, вы думали, разработчики программ берут лицензионные ключи, которые потом продают за 1500 рублей? У них есть свой keygen, а у меня его не было.

Я снова ощутил себя вершителем судеб, пока не нашёл на форумах информацию о том, что такие программы пишут студенты 3-4 курса технических ВУЗов.

Что? Студенты? Я не какой-то там студент! Я Криса Касперски читал!

Мне было мало, и я горел страстью! Мне нужно было творить, писать, создавать! Только ООН могла мне помешать вытворять то, что я хочу. И я написал в среде Delphi 7 целую базу данных различных программ. Например, программу для «склеивания» файлов, которую я написал, пытаясь создать собственный WinRar, что, кстати, не получилось. Пародия на Bourne Shell, за которую мне ужасно стыдно до сих пор.

Программа для вычисления контрольных сумм как файлов, так и текстов, была написана за один присест, трояны-шифровальщики (на самом деле, серьёзные вайперы), программы для создания больших изображений путем «склеивания» массы маленьких, патчеры бинарных файлов, файловые шредеры и даже простой чат с клиент-серверной архитектурой, поддержкой шифрования сообщений и поддержкой ника (сетевого имени). Ещё я написал аналог программы «Поиск» для Windows XP, но это уже в прошлом.

В конце концов, я изрядно устал. Мне казалось, что я написал вообще всё, что можно было написать. Мне стало скучно. Мне казалось, что писать программы — это несерьёзно. Я правда так думал!

Переход на язык Си и создание программы для шифрования файлов

Я задумался, смогу ли я написать ядро операционной системы, интернет-браузер, полиморфного многовекторного червя с функционалом анонимного удалённого управления, сайт вроде “ВКонтакте”? Ответ был: нет. И я обратил внимание на язык программирования, как мне казалось, более серьёзный, сильный, взрослый, круче, чем языки Object Pascal и Delphi. Это был язык Си.

Так я начал карабкаться на ступень, на которой уверенно стоят не просто школьники, перебирающие пароли к чужим серверам, а настоящие титаны инженерной мысли мира IT вроде Эрика Реймонда, Ричарда Столлмана и Линуса Торвальдса. Как оказалось, то, что я делал раньше, скорее всего, делали и они. Но сейчас для них это просто мелочь, недостойная внимания.

Писать программы можно научиться за короткое время, но нельзя за короткое время научиться думать точно.

Я даже не знал, что это такое — думать точно. Я даже не думал! Я просто делал и всё. Как карта ляжет. Изучение языка Си открыло мне глаза на настоящее программирование. Я поставил GNU/Linux Debian рядом с уже сотни раз переустановленной Windows XP, установил gcc, cppcheck, Kate и начал постигать самую серьёзную, на мой взгляд, ступень программирования.

Я узнал, что такое динамическое выделение памяти, как устроены языки программирования и чем они отличаются, что такое типизация, указатели и их арифметика, как компилятор превращает исходные тексты в ассемблерный лист и позже собирает из него бинарный файл.

Я понял, почему я устал, почему исписался. Мне не хватало настоящего хардкора, если хотите, Мужъского ТруЪ. Я понял, что в течение нескольких лет я занимался учебными стрельбами, а не реальными баталиями.

Я решил вернуться к своей первой задумке, а именно программе для шифрования файлов. К тому времени я уже перепробовал массу программ для шифрования файлов и удовлетворить мои потребности смогла только GnuPG. Но зачем так сложно? Делать нужно просто, будто для дураков. Первое, что я сделал, это поставил задачу.

Нужно зашифровать файл так, чтобы никто, даже директор ЦРУ, никогда не получил открытый текст, не зная пароля или не имея доступа к ключевому файлу. Пароль же перебрать нельзя, а если и можно, то ждать придётся неисчислимое количество времени. Взлом шифротекста методами криптоанализа должен быть невозможен в принципе.

Задача казалась непосильной, но позже стала тривиальной. Я более или менее изучил язык Си и начал писать ту самую неповторимую программу, которую писал когда-то. Я сразу понял, увидел, что должно получиться.

Меня как будто осенило — старая версия программы была просто не моего уровня.

Я вдруг чётко стал видеть путь и инструменты, которые нужно использовать, чтобы получить максимум, приложив минимум усилий. Но заразился страшной болезнью, которой страдают все программисты, переходя на новый, продвинутый уровень: Сишностью.

Я больше не могу видеть свой старый код. Меня от него трясет и корёжит. Правда. Я считаю, что следующий код хорош, но любой другой просто шлак, даже мой, что заставляет меня писать аккуратно, как будто я программирую ракету для миссии на Нептун! Что со мной? Все нормально. Просто, я расту над собой. Если ты новичок, тебя ждёт то же самое. Всех ждёт!

Первой прочитанной научной книгой стала пиратская версия книги Брюса Шнайера «Прикладная криптография», которую «проглотить» оказалось не так просто. Она оказалась мне не по зубам, и начался тяжёлый подъем в гору просветления.

«Криптография бывает двух типов: криптография, которая помешает читать ваши файлы вашей младшей сестре, и криптография, которая помешает читать ваши файлы людям из правительства».
«Прикладная криптография», Брюс Шнайер.

Я медленно, но верно изучил алгоритмы шифрования, выбрав пять наиболее понравившихся мне, а позже выбрав шестой, Twofish, режимы шифрования, выбрав в итоге CFB (режим обратной связи по шифротексту), за что спасибо учёным, авторам статьи на сайте одного белорусского ВУЗа. Я выбрал всё лучшее на тот момент, но не прочитал главного — как делать не надо. Снова.

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

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

Сейчас разрабатываемую и поддерживаемую мной программу я использую сам для шифрования файлов размером до 2 ГБ включительно. Мне больше и не надо. Программа свободна и использовать ее может кто угодно и для чего угодно.

Пароль, из которого генерируются ключи шифрования, действительно не перебрать на компьютерах не то что сегодняшнего дня (2021 года), а, скорее всего, вообще никогда. Криптоанализ шифротекстов, насколько я могу судить, неэффективен.

Единственный шанс получить открытый текст из шифротекста без знания пароля — это украсть открытый текст до шифрования. Как и у WinRar, копию которого я когда-то безуспешно пытался написать. Размер самой программы, точнее, её консольной версии, около 90 КБ, графической версии — около 480 КБ.

Такие малютки, но столько мощи! Сегодня такие программы уже не пишут. Ну разве что ребята из проекта GNU. Я действительно горжусь тем, что создал, пройдя по-настоящему тяжёлый и долгий путь. Мне ещё многому предстоит научиться, многое сделать, но я чётко вижу, куда идти и что нужно делать, а, главное, знаю, как не надо делать.

Я сделал это. Сделаешь и ты. Главное, подогревать в себе огонь тем, что по-настоящему разжигает страсть!

Выглядит игра следующим образом: пользователям показывается кусок кода на С/С++, после чего им необходимо выбрать, кто написал его. В верхней части сайта есть две кнопки для этого: Real («Реальный человек») и GPT2 (нейросеть). Там же после первого выбора будет показан счёт с количеством верных и неправильных ответов.

К слову, именно модель GPT2 774M и легла в основу всего проекта. Её тренировали на 10 000 самых популярных пакетах Debian, написанных на С/С++. При этом «реальные куски кода» для DoesNotExist.codes также были взяты из этих пакетов.

Источник: DoesNotExist.codes

Чаты программистов по технологиям

JavaScript

Slack Workspace для обсуждения всего, что связано с JavaScript. При выборе интересующих вас тем, во время регистрации, нажимайте на сами темы, а не на чекбоксы. В чате состоит более 700 участников.

Сообщество JS программистов в Telegram. Больше тысячи участников.

Frontend

Slack Workspace посвящённый вебу и всему что с ним связано. Имеет более пяти тысяч участников. Сейчас больше активности в их Telegram-чате.

Slack Workspace  фронтэндеров из Санкт-Петербурга. Сообщество устраивает оффлайн встречи. Сейчас насчитывает более 1700 участников.

Python

Slack Workspace сайта Python.ru. В нём состоит более трёх тысяч человек. Можно задать вопросы по Python, Flask, Django и другим технологиям. В чате организуют оффлайн встречи программистов.

PHP

Группа в Telegram для программистов новичков в PHP. Почти две тысячи участников.

iOS

Slack Workspace где можно обсудить Swift, Objective-C, Cocoa, машинное обучение, реактивное программирование и множество других тем. Сейчас в чате более трёх тысяч участников.

Android

Gitter сообщества android разработчиков. Есть отдельный чат для программистов, использующих Xamarin-технологии.

Java\Kotlin

Группа в Telegram обо всём что связано с Java и Kotlin. Полторы тысячи участников.

Data Science

Сообщество Open Data Science с сотнями каналов на различные темы, связанные с наукой о данных, машинным обучением и ИИ.

Go

Сообщество Gо программистов в Telegram. Более четырёх тысяч участников.

GameDev

Slack Workspace обо всём что связано с разработкой игр. Можно обсудить геймдизайн, GFX, iOS, Android, Unity, Unreal Engine и многое другое. Более двух тысяч участников.

С++

Группа в Telegram для новичков в С++. Можно задавать простые вопросы о языке и IDE. Более трёх тысяч участников.

Группа в Telegram для более сложных вопросов по C\C++. Более четырёх тысяч участников.

Программирование

В Slack-чате курсов по программированию Хекслет можно обсудить всё, что связано с разработкой. В нём состоит более восемнадцати тысяч участников.

Другие чаты программистов

Помогите нам составить наиболее полный список русскоязычных чатов программистов. Делитесь ими в комментариях. Мы добавим их в подборку.

На Laconic Machine Learning появился огромный материал на тему Computer Science. В нём авторы ресурса попытались воссоздать четырёхлетний курс обучения компьютерным наукам при помощи видео с YouTube. В общей сложности для этих целей было использовано 1079 обучающих видеоролика.

Материал разделён на сегменты, соответствующие учебному плану в типичном американском университете: 40 курсов, 4 академических года по 2 семестра в каждом.

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

Стоит отметить, что в рамках предлагаемого плана обучения можно найти изучение машинного обучения, создание мобильных приложений под iOS и Android, робототехнику, компьютерное зрение и много чего ещё интересного.

Сами авторы материала отмечают, что их подборка хоть и является крайне полезной, всё же не заменит полноценного обучения в университете. Но при этом она может помочь разобраться в Computer Science как студентам, так и тем, кто так и не поступил в вуз.

Источник: Laconic Machine Learning

Сама игра написана языке Си. Но для удобства большинства своих зрителей, в видео используется объяснение на примере псевдопитона.

В момент, когда игрок находится на земле, скорость его перемещения вычисляется при помощи функции:

Что же касательно вычисления скорости в момент нахождения в воздухе, то за это отвечает другая функция:

На основе этой базы строятся такие «фишки» серии Quake как распрыжка, wall running и зигзагинг. При этом, стоит отметить, что в дальнейшем все эти движения стали частью и других серий. Так, благодаря использованию одной из версий id Tech в качестве основы для движка Half-Life, чуть позже Counter-Strike также стала известна распрыжками.

Источник: Matt’s Ramblings

Одной из самых интересных работ отечественного программиста можно назвать инструмент вычисления хэшей MD5. Его код оформлен в виде круга. Одной из главных сложностей при уменьшения размеров утилиты Курдюков назвал длину таблицы MD5. Она, с учётом констант, составляет 64 х 4 байта.

Были и не менее интересные работы от других участников. Например, японский разработчик Юсуки Эндо написал приложение, которое выводило надпись «May the IOCCC be with you» анимированную в стиле начальных титров из Star Wars:

Отметим, что главной задачей участников соревнования от IOCCC была разработка программы на языке Си, которая была бы максимально запутанной и нечитабельной. В то же время приложение должно было успешно собираться, решать какую-то задачу и весить не более 4 КБ.

Источник: IOCCC

В комментариях подсказывают, что в реальности машинный код получается более оптимизированным. По этой ссылке вы найдете компилятор из языка Си в Assembler, который подсвечивает соответствующие друг другу строки программы на С и Assembler.

0:00 Как программа на C считает числа Фибоначчи

2:28 Как скомпилировать и дизассемблировать программу

3:20 Разбор машинного кода

Си применяют в сферах, где важен код, наиболее тесно взаимодействующий с «железом». Под влиянием Си появились языки C++, C#, Java и Objective-C.

Си иногда называют подмножеством C++ или «C++ без классов», но это не совсем верно. Почему это не так, можно узнать в статье про C++.

Си поддерживает исключительно процедурное программирование. Никаких классов, ООП, наследования — только функции и структуры. К основным особенностям языка относятся:

• доступ к памяти через указатели (особые переменные, в которых хранится адрес объекта);
• активное использование структур и объединений;
• чистый стиль программирования (код проще отлаживать, но сложнее писать).

Си обычно используется в довольно специфичных и сложных задачах, потому что более лёгкие задачи проще сделать с помощью высокоуровневых языков. Мы отобрали несколько наиболее популярных применений Си.

Оптимизация участков кода на C++

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

Но если нужна действительно высокая скорость, лучше переписать часть кода на ассемблере.

Информационная безопасность

Сюда относятся сложные хакерские приёмы. Среди них:

• Использование уязвимостей: переполнения буфера, двойные удаления (повреждения кучи).
• Инъекция (сокрытие) кода. Если получить доступ к другому процессу, используя уязвимость, то можно спрятать свой код внутри чужого и заставить процесс выполнять его. Теперь скрытый код будет жить в «невинном» процессе, спрятанном от глаз пользователя.
• Перехват (hooking). Если вы хотите мониторить чьи-то взаимодействия с системой (нажатие клавиш, открытие файлов), вам, как правило, нужно вызывать отслеживающий код всякий раз, когда пользователь что-то делает. Для этого вы заменяете какой-либо фрагмент API операционной системы вашим кодом.

Почти для всех этих применений используется PIC код (position-independent code — код, не зависящий от адреса). Он может выполняться в любом месте памяти, независимо от того, где находится и кто его запустил. У PIC-кода нет доступа к глобальным переменным и таблицам, поэтому C++ для его написания не подойдёт (классам C++ нужны глобальные таблицы для реализации наследования).

Код ядра

Код, который выполняется в режиме ядра (kernel mode) имеет полный доступ к памяти и оборудованию: RAM, GPU, жёсткому диску. В режиме ядра работают:

• Аппаратные драйверы — здесь без доступа к железу не обойтись. Драйверы являются посредниками между пользовательским кодом (не в режиме ядра) и оборудованием.
• Ядро операционной системы. На Си, кстати, написано множество ядер ОС, в том числе Unix и Android.

Использовать для всего этого код на C++ почти невозможно, поскольку в режиме ядра нет доступа к тем же глобальным таблицам, о которых говорилось выше. Иногда в режиме ядра тоже необходим PIC код — например для загрузчика (bootloader). Загрузчик — самая первая программа, выполняющаяся при запуске ПК. Биос извлекает её из жёсткого диска, помещает в память и говорит процессору запустить эту часть памяти.

Embedded-разработка

Для программирования встраиваемых систем часто используется как Си, так и C++. Но Си имеет преимущество, поскольку позволяет разрабатывать встроенное ПО при ограниченных ресурсах — например когда у микроконтроллера очень мало RAM. Помимо Си также может пригодиться знание ассемблера (как вариант, ARM-ассемблера) для написания ассемблерных вставок, чтобы ещё больше оптимизировать код и получить доступ к специфичным инструкциям процессора.

Да, сейчас запросов на разработку современных продуктов на языке С относительно немного. Как показывает наш портфель проектов, выше спрос на С++. Однако, в программисте мы видим, прежде всего, инженера, способного разобраться со сложными вопросами, которые, возможно, до него ещё никто не решал. Поэтому знание основ С — это плюс для общеинженерного развития специалиста.

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

В мобильной разработке язык Си может использоваться при написании игр или для создания native методов Java классов, реализация которых использует вызовы JNI.

Язык Си считается языком низкого уровня. Начав изучение программирования с него, специалист будет лучше понимать базовые вещи в разработке. Кроме того, существует множество языков программирования, синтаксис которых берёт начало у языка Си, например C++, Java, C#. Знание «первоисточника» наверняка облегчит их изучение.

Тем не менее, базу (классические структуры данных, битовые операции) можно изучать на примерах ООП-языков, особой разницы нет. Кроме того, зачастую такой уровень погружения в детали, который даёт Си, на практике не нужен.

Программист высокого уровня должен иметь широкий кругозор и не замыкаться в рамках одной парадигмы программирования или языка. Сегодня в России не так много специалистов, хорошо владеющих «низкими» языками программирования, а знание Си может стать важным конкурентным преимуществом.

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

Однако изучать базу можно и на примере других языков. Возможностей очень много, поэтому знать именно язык Си совсем не обязательно.

Изучать какой-либо язык программирования, не имея планов по дальнейшему применению этих знаний на практике, к сожалению, бессмысленная затея. Знания, не подкреплённые практикой, как минимум будут неполными, ну а как максимум — «улетучатся» через полгода-год.

Если есть интерес заглянуть поглубже и понять работу компьютерных систем, надо ориентироваться не столько на язык, сколько на разработку какого-либо системного программного обеспечения. Например написать собственный драйвер под какое-либо устройство (например подключаемое через USB). В процессе работы над подобной задачей потребуется изучить, каким образом происходит взаимодействие операционной системы и внешнего устройства, особенности системных API и протоколов и многое другое.

Несколько реализованных проектов по разработке системного ПО разных классов — и у вас уже будет не только понимание базовых принципов функционирования операционных систем, но и ценный практический опыт. Естественно, реализация будет на языке C/С++!

Для изучения базовых структур данных и алгоритмов подойдет большинство языков программирования. Для какой-то конкретной области — наоборот, понадобится знание определённого языка. И маловероятно, что это будет именно Cи. Так что на этот вопрос нет однозначно правильного ответа. «Настоящий» программист — это любой человек, который пишет код и получает за это деньги. И большинство таких ребят начинали с совершенно разных языков. Всё остальное — это темы холиваров, не более.

Но сам вопрос — острый, и фокус в нём вовсе не на Cи, а на том, какую технологию выбрать для изучения сейчас, чтобы принимать участие в реальных проектах в будущем. Конечно, верный ответ тут: «любую».

Ведь язык — это лишь инструмент для человека, который знает математику, алгоритмы и архитектуру систем. Но на этапе обучения хочется конкретики. Учить что-то сейчас — лучше, чем не учить ничего, но многообразие технологий пугает.

Я считаю, что Cи как первый язык — это неудачный выбор. Там нет ни одной интересной парадигмы. Все аргументы вроде «Cи — основа основ», «Cи самый быстрый», «Cи позволяет лучше понимать базовые вещи» не выглядят убедительными. Си важный язык для определённых экосистем, например микроконтроллеров, утилит и ядра ОС, драйверов, встраиваемых систем и т. п. Но это довольно узкие области. Человек, который учит Си конкретно для этих кейсов, обычно не руководствуется понятиями «трушности» технологии.

Для обучения на первоначальном этапе я бы посоветовал рассматривать Java или C++, у них хорошая ООП-парадигма и много интересных новинок в стандартах. Кроме того, они более универсальные и востребованные. В C++ порог входа чуть выше. Также неплохим вариантом будет изучение JavaScript. По тем же причинам.

Да, действительно, в ряде случаев изучение C/С++ улучшает понимание того, как работает компьютер и способствует значительному улучшению качества кода, написанного даже на других языках. Особенно это полезно программисту, для которого единственным известным языком является какой-нибудь достаточно высокоуровневый язык (Python, JavaScript, PHP). С другой стороны, возможно, вы уже знакомы с основами работы компьютера и не собираетесь программировать на C/C++. Тогда терять время на изучение этих языков не стоит. Можно легко проверить себя, ответив на вопросы ниже. Если вы чётко представляете ответы на них, то, скорее всего, C/C++ вам нужно изучать, только если вы собираетесь писать программы именно на этих языках:

1. Как сложные объекты передаются в функции в известном мне языке программирования? Сколько времени и памяти тратится при такой передаче?
2. Как рассчитать требуемый объём стека для рекурсивной функции, если известна максимальная глубина рекурсии?
3. Что такое выделение и освобождение памяти? Где в моей программе память выделяется, а где освобождается? Как спрогнозировать, сколько памяти будет потреблять моя программа?
4. Что такое полиморфизм в объектно-ориентированном программировании?
5. Что такое шаблоны (паттерны) проектирования программ? Известны ли вам какие-нибудь из них?

Язык Си действительно один из самых старых и популярных инструментов для разработки ПО. Его используют там, где необходима высокая производительность и низкоуровневая работа с железом: системное программирование, работа с микроконтроллерами, разработка операционных систем. Очевидно, что программисты, работающие над ПО такого рода, должны хорошо знать свой основной инструмент.

Обязательно ли знать Си современному веб- или мобильному разработчику? Я думаю, что нет. В большинстве случаев в ежедневной разработке знание Си ему не потребуется. С другой стороны, будет ли вредно понимание основ и концепций этого языка? Точно нет. Я уверен, что интересы «настоящего» программиста (в моем субъективном понимании) должны выходить за пределы ежедневной рутины.

Поэтому, я считаю, что трата времени на изучение основ этого языка — это долгосрочная инвестиция в своё профессиональное образование. Конечно, с оговоркой на то, что при выборе глубины изучения нужно руководствоваться здравым смыслом.

Не должен.

Но попробовать стоит! Любой язык программирования — это инструмент для решения определённого круга задач. Чем большим количеством инструментов ты владеешь, тем больше разнообразных проблем ты можешь решить, а, следовательно, тем более ценным специалистом ты являешься. А если ты в начале своего пути в профессии, то тут как в бурной молодости: нужно попробовать всё, чтобы решить, что твоё, а что — нет.

Изучение Си действительно способствует пониманию многих фундаментальных вещей. Лично я в университете знакомство с алгоритмами и структурами данных начинал именно на Си, потому что программирование на таком низкоуровневом языке помогает разобраться во всех нюансах, которые инкапсулированы в современных языках высокого уровня, и лучше понимать, как работают приложения.

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

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

Однозначно можно сказать только то, что грести всех под одну гребёнку неверно. И разделение на «настоящих» и «ненастоящих» программистов — одна из попыток людей систематизировать то, что не только не поддаётся систематизации, но и не нуждается в ней. Абсолютно равнозначным в этой ситуации будет такой вопрос: «Должен ли “настоящий” программист С знать другие языки?». Да, С — это старый, завоевавший уважение язык, повлиявший на многие другие, но в 2019-м году нет явной необходимости его учить, чтобы уметь программировать, закрывать задачи бизнеса или понимать внутренние процессы в приложениях. Знание С и умение, например, работать с указателями, помогает в работе, это факт. Очень сильно помогает быстро выучить какой-нибудь С-подобный язык, это тоже правда. Организует и приучает к строгости, возможно. Но так, чтобы «должен, иначе не настоящий программист» — вряд ли.

В своей практике (кроме периода, когда я профессионально разрабатывал на С/С++) я несколько раз сталкивался с ситуациями, когда проще написать на С/С++, чем на каком-то другом языке, но я абсолютно уверен, что это скорее исключения, чем что-то происходящее с людьми часто. Информационные технологии развиваются гораздо динамичнее, чем это может себе позволить любой язык программирования, тем более такой архаичный, как С, поэтому и появляются новые языки, выполняющие поставленные перед ними задачи лучше других. Да, разработчики этих новых языков зачастую используют С «под капотом», но программисту знать об этом нужно в исчезающе малом количестве случаев.

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

Ответ на этот вопрос будет зависеть, прежде всего, от области разработки: например веб-разработчику знание языка С в его профессиональной карьере пригодится навряд ли.

При этом разработчики по мере роста своего профессионализма в области разработки ПО неизбежно приходят к необходимости изучения С, поскольку на этом языке написан огромный массив кода, лежащий в основе множества современных ИТ-продуктов и систем. И даже в тех случаях, когда речь не идёт о непосредственном использовании С, идеи этого языка так или иначе применялись в других языках, его влияние переоценить невозможно.

С другой стороны, С несёт в себе врожденную сложность — требует от программистов глубокого понимания архитектуры компьютеров, адресной арифметики и ряд других моментов, что очень полезно для общего развития специалиста.

Можно говорить, что если разработчик не испытывает проблем с пониманием адресной арифметики, то он может мыслить системно и делает это серьёзном уровне, а значит, в теории сможет решать более комплексные практические задачи.

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

Сейчас кадров с таким бэкграундом в подготовке становится всё меньше, поэтому заявление «если не знаешь С — то ты не программист» теряет актуальность. Прикладные задачи можно спокойно решать и без системного понимания сферы ИТ и места в ней поставленной задачи.

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

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

Программисту может потребоваться знание языка C в зависимости от специфики его задач. Например, если программист пишет драйверы для операционной системы, скорее всего ему нужно знать C и Assembler. Если он разрабатывает веб-интерфейсы и программирует сайты, ему точно не пригодится этот язык.

Если же говорить о программистах-разработчиках-исследователях, которые пишут не просто реализацию какого-то известного подхода, то скорее уместно говорить о Python и С++. Первый хорошо подходит для прототипирования, а последний часто используется в продакшн-коде крупных компаний. У нас это основные языки программирования, в целом всё зависит от того, в какой отдел и на какую позицию приходит работать человек. Сейчас язык C встречается мало где, но есть ниши, где требуется знание именно этого языка. Однако лично я не считаю C обязательным языком для каждого программиста.

Есть очень много высокоуровневых языков: для Ruby on Rails, например, достаточно 3–4 месяца, чтобы его освоить хотя бы на базовом уровне. Си — более академический язык, и даёт фундамент для понимания, как работают другие языки. Люди с опытом в Си имеют больше фундаментальных знаний, а также представление о том, как устроены языки программирования, и какие операции и логика будут/могут влиять на память, CPU и другие компоненты приложения и железа. Это связано с тем, что данный язык требует большого внимания к этим деталям и позволяет через код влиять на них. Тратить или не тратить время на изучение — решает каждый сам в зависимости от своих целей. Если говорить о разработке промышленных решений, то знание языка Си пригодится. Если речь идёт о разработке сайтов, панелей админок и небольших стартапов — то знаний других языков будет достаточно.

Если человек хочет стать хорошим строителем, он должен знать, как устроен дом: понимать, как делается кирпичная кладка, какие материалы нужно использовать, чтобы дом выдержал все катаклизмы природы, а также то, как сделать дом удобным и безопасным для будущих новосёлов. По этой же причине хороший программист должен понимать, как устроены базовые алгоритмы, а также какие и в каком количестве программа потребляет системные ресурсы. Для этого наилучшим образом подходит язык Си, где взаимодействие с машиной происходит на достаточно низком уровне, но который, в отличие от языка Ассемблера, обладает всё теми же конструкциями, что и большинство языков более высокого уровня.

Кто-то становится журналистом, кто-то писателем, а кто-то учёным. Понятно, что все эти профессии объединяет одно — способность чётко и правильно выражать свои мысли: журналисту — в публицистическом стиле, писателю — в художественном, учёному — в научном. Точно так же и изучение Си способствует вырабатыванию собственного стиля, который может быть применён в дальнейших языках, специализирующихся на своих задачах. Знания Си одинаково полезны будут и системному программисту, и прикладному, и веб-технологу. Стоит только вспомнить, какие языки используют похожий синтаксис: C++, C#, Java, JavaScript, PHP, Perl, AWK. И многие другие.

Ещё один аргумент в пользу того, чтобы начать изучение программирования именно с Си, заключается в том, что этот язык не прощает ошибок. Здесь не получится небрежно обойтись с памятью, уповая на сборщика мусора или на то, что интерпретатор пропустит мимо выход за пределы массива. Здесь нет ни интерпретатора, ни сборщика мусора. Поэтому такие ошибки будут сразу видны, и в сотый раз получив сообщение от операционной системы Segmentation fault, ученик начнёт задумываться, что, в конечном счёте, приведёт к формированию правильного стиля кода и поможет ему в дальнейшем в освоении новых языков.
Конечно, освоивший Си с лёгкостью перейдёт на более высокоуровневые инструменты, но навык хорошего стиля, при достаточном уровне проработки на Си, у такого ученика останется навсегда. А если ученик особо пытливый, он захочет разобраться, как именно исполняется его программа на вычислительной машине и откроет скомпилированный файл в дизассемблере. Благодаря тому, что Си не оброс большим количеством наслоений и абстракций, не составит большого труда сопоставить полученный код с тем, что было изначально. А это первый шаг к изучению языка ассемблера. Сделав такой шаг, ученик встаёт уже на путь системного программиста, программиста микроконтроллеров или исследователя программ. Удивительный мир низкого уровня особенно понравится перфекционистам, которые захотят досконально изучить принципы функционирования вычислительной машины и полностью контролировать её.

Недаром язык Си называет в шутку «кроссплатформенным ассемблером». И хотя словосочетание само по себе является оксюмороном, доля правды в этой шутке всё же есть. Например, интерфейс системных вызовов в UNIX-подобных операционных системах осуществлён именно с использованием библиотек Си. На этом языке также разрабатываются операционные системы, драйверы, программное обеспечение для микроконтроллеров, на этом языке пишутся компиляторы и трансляторы. Компилятор gcc, используемый для компиляции программ на Си — одна из главных программ, входящая в базовую комплектацию любого дистрибутива Linux, поскольку сборка остальных пакетов и модулей происходит путём компиляции исходников именно на этом языке. Стоит также отметить, что большинство технологий и средств разработки более высокого уровня изначально были написаны на Си: интерпретируемые языки вроде Python, Perl и PHP, виртуальная машина Java и многое другое.
Время выполнения того или иного алгоритма и потребление им памяти максимально «честно» можно вычислить именно на языке Си, ведь никаких дополнительных накладных расходов при выполнении программы не происходит. Вот почему это особенно полезно для проверки себя на правильность реализации тех или иных алгоритмов. В учебной программе бакалавриата МАИ уже пять лет успешно изучается курс Си, вытеснив собой язык Pascal. И хотя Pascal даёт возможность понять работу основных алгоритмов, в нём многие ошибки контролируются на уровне синтаксиса. Вот почему важно делать много ошибок на самом начальном этапе, разбирать их, контролировать и не допускать в будущем. Также важно понимать не только ход работы алгоритма, но и представлять, сколько такой алгоритм потребляет системных ресурсов. Классический синтаксис важно изучить, чтобы не возникло проблем с изучением других технологий в будущем. Вот главные причины, почему стоит начать изучение программирования с этого замечательного языка.

Итак, должен ли тру-программист знать Си?

В общем и целом, эксперты сошлись на мнении, что не должен.

Си может дать более глубокое понимание того, как работают другие языки, как код влияет на железо и так далее. Однако, нужно ли вам это глубокое понимание в обязательном порядке? Сейчас существует много языков и много направлений в разработке, где Си либо не нужен, либо нужен редко. Да, есть определённый круг задач, где знание Си необходимо. Но мы ведь говорим не про отдельные кейсы, а про всех программистов в целом?

С другой стороны, программирование на таком низкоуровневом языке помогает разобраться во всех нюансах, которые инкапсулированы в современных языках высокого уровня, поэтому Си можно изучать для саморазвития и повышения своего профессионального уровня.

Но всё-таки, в первую очередь учите те языки, которые нужны для решения ваших задач, а остальные оставьте для общего развития.

Напоминаем, что вы можете задать свой вопрос экспертам, а мы соберём на него ответы, если он окажется интересным. Вопросы, которые уже задавались, можно найти в списке выпусков рубрики. Если вы хотите присоединиться к числу экспертов и прислать ответ от вашей компании или лично от вас, то пишите на experts@tproger.ru, мы расскажем, как это сделать.

Примечание Для дизассемблирования в этой статье используется IDA Pro, но многие её функции (например блок-схемы, перевод в псевдокод и т. д.) можно найти в качестве надстроек в бесплатных дизассемблерах (radare2). Более того, для лучшего понимания имена некоторых дизассемблированных переменных были изменены с «v20» на имена, которые были у них в С. Также в этой статье исполняемый файл был скомпилирован в 64-битной версии, а для дизассемблирования используется 64-битная версия IDA Pro. Это на случай, если вы захотите повторить всё самостоятельно, потому что это может повлиять на конечный результат (например, на массивах будет сильное различие 32 и 64-битных версий, а также в 64-битной версии регистры становятся в два раза больше).

Массивы

Итак, начнём с массивов. Сначала рассмотрим код на Си:

Эти 12 строк кода превращаются в довольно внушительный блок машинного кода. Давайте рассмотрим его детально:

При инициализации массива с константным размером компилятор просто инициализирует длину массива через локальную переменную.

Во время компиляции будет выделено место только под одно значение массива litArray[0], которое и будет использоваться (можно увидеть на скриншоте ниже). Такой приём позволяет компилятору значительно увеличить производительности приложений.

Сначала длина массива сохраняется в локальную переменную ArraySize, затем вычисляется максимальное и минимальное индексное значение, а также длина всего массива, а затем под неё выделяется память.

При объявлении массива с предопределёнными значениями компилятор сохраняет каждое значение в свою переменную, которая представлена индексом массива (например objArray4 = objArray[4]).

Так же как и с предопределёнными значениями, компилятор создаёт новую переменную для указанного индексного значения при инициализации элемента массива через индекс.

При извлечении элемента массива значение элемента берётся по указанному индексу и записывается в нужную переменную.

При создании матрицы сначала её размер устанавливается в соответствии со значениями row и col. Затем рассчитываются максимальный и минимальный индексы для строк и столбцов, которые используются для расчёта базового местоположения и общего размера матрицы в памяти.

При вводе в матрицу сначала определяется местоположение желаемого элемента массива с использованием базового местоположения матрицы. Затем содержимое указанного элемента массива устанавливается на желаемое входное значение (т.е. 1337).

При извлечении значения из матрицы происходят такие же вычисления, как и при внесении значения в неё. Однако при этом ничего не записывается — содержимое извлекается и записывается в нужную переменную (например MatrixLeet).

Указатели

Теперь, когда мы понимаем, как массивы используются и выглядят в машинном коде, давайте перейдём к указателям.

Давайте сразу разберёмся в машинном коде:

Сначала мы присваиваем переменной num значение 10.

Затем указателю pointer присваивается адрес переменной num.

Вывод переменной num на экран.

Вывод переменной pointer на экран.

Вывод адреса переменной num происходит с помощью инструкции lea (загрузка результирующего адреса) вместо mov.

Вывод адреса переменной num через указатель pointer.

Вывод адреса переменной pointer происходит с помощью инструкции lea вместо mov.

Динамическое распределение памяти

В этой статье будут рассмотрены следующие виды динамического распределения памяти:

1. malloc.
2. calloc.
3. realloc.

malloc — динамическое выделение памяти

Сначала разберёмся в коде:

Прим. перев. В оригинале статьи выделяется 11 байтов, хотя правильно будет 12. В конце строки ещё добавляется символ с кодом 0.

В этой функции выделяется место под 11 символов с помощью malloc(), а затем в выделенное пространство памяти копируется «Hello World».

Теперь давайте посмотрим на машинный код:

Примечание Во время сборки вы можете увидеть инструкции «nop». Эти инструкции были специально размещены на этапе подготовки к статье, чтобы различные части кода было проще понимать.

При использовании malloc() размер выделенной памяти (0x0B) сначала перемещается в регистр edi. Затем системная функция _malloc вызывается для выделения памяти. Выделенная область памяти затем сохраняется в переменной ptr. Потом строка «Hello World» разбивается на «Hello Wo» и «rld», поскольку она копируется в выделенное пространство памяти. Наконец, вновь скопированная строка «Hello World» выводится на экран, а выделенная память освобождается с помощью функции _free.

calloc — динамическое чистое выделение памяти

Посмотрим на код:

Как и в методе malloc(), место для 11 символов выделяется, а строка «Hello World» копируется в указанное пространство. Затем вновь перемещённый «Hello World» распечатывается, и выделенное пространство памяти освобождается.

Динамическое распределение памяти через calloc() выглядит почти идентично динамическому распределению памяти через malloc() в машинном коде.
Во-первых, пространство для 11 символов (0x0B) выделяется с помощью системной функции _calloc. Затем строка «Hello World» разбивается на «Hello Wo» и «rld„, поскольку она копируется во вновь выделенную область памяти. Затем вновь перемещённая строка “Hello World» выводится на экран, а выделенная область памяти освобождается с помощью функции _free.

realloc — динамическое перераспределение памяти

Сначала посмотрим код.

В этой функции память для 11 символов выделяется с помощью malloc(). Затем «Hello World» копируется в только что выделенное пространство памяти, прежде чем указанное расположение памяти перераспределяется, чтобы соответствовать 21 символу.

Прим. перев.: Должно быть 22 символа. Снова автор забыл символ с кодом 0, используя realloc()

Наконец, «1337 h4x0r @nonymoose» копируется в только что перераспределённое пространство. Наконец, после вывода на экран память освобождается.

Теперь посмотрим машинный код:

Сначала память выделяется с помощью malloc(). Затем, после вывода на экран только что перемещённой строки «Hello World», вызывается realloc() для переменной ptr (которая представляет переменную mem_alloc в коде), а также передаётся новый размер 0x15 (21 в десятичном виде). Затем «1337 h4x0r @nonymoose» разбивается на «1337 h4x„, “0r @nony», «moos» и «e„, поскольку он копируется в только что перераспределённое пространство памяти. Наконец, пространство освобождается с помощью функции _free.

Программирование сокетов

Далее мы рассмотрим программирование сокетов, разобрав очень простую систему клиент-серверного TCP-чата.

Прежде чем мы начнём разбирать код сервера или клиента, важно указать следующую строку кода в верхней части файла:

Эта строка определяет константу PORT как 1337. Эта константа будет использоваться как на клиенте, так и на сервере в качестве сетевого порта, используемого для создания соединения.

Серверная часть

Сначала посмотрим на код:

Сначала создаётся файловый дескриптор сокета server с доменом AF_INET, типом SOCK_STREAM и кодом протокола 0. Далее настраиваются параметры сокета и адрес. Затем сокет привязывается к сетевому адресу (порту), и сервер начинает прослушивать указанный порт с максимальной длиной очереди 3. После получения соединения сервер принимает его в переменную sock и считывает переданное значение в переменную value.

Наконец, сервер отправляет строку serverhello по соединению до возврата функции.

Теперь давайте разберём его в машинном коде:

Сначала создаются и инициализируются переменные сервера.

Затем создаётся файловый дескриптор сокетов server с помощью системной функции _socket. Параметры для функции — протокол, тип и доменное имя передаются с помощью регистров edx, esi и edi соответственно.

Затем вызывается _setsockopt для задания параметров сокета в файле дескриптора “server».

Инициализируется серверный адрес с помощью adress.sin_family, address.sin_addr.s_addr и address.sin_port.

После того как сервер был сконфигурирован, он привязывается к интернет-адресу с помощью _bind.

После привязки сервер слушает сокет, передав файловый дескриптор server. Максимальная длина очереди равна 3.

Как только соединение установлено, сервер принимает соединение сокета в переменную sock.

Затем сервер считывает переданное в переменную value сообщение с помощью _read.

В конце концов, сервер отсылает сообщение serverhello через переменную s в машинном коде.

Клиентская часть

Сначала разберёмся в коде:

Сначала создаётся файловый дескриптор сокета sock с помощью переменной домена AF_INET типа SOCK_STREAM и кода протокола 0. Затем memset используется для заполнения области памяти server_addr нулями до того, как информация об адресе будет установлена ​​с помощью server_addr.sin_family и server_addr.sin_port. До того как клиент подключится к серверу, информация об адресе преобразуется из текстового в двоичный формат с использованием inet_pton. После подключения клиент отправляет строку helloclient и затем принимает ответ сервера в переменную value. Наконец, переменная value выводится на экран, и происходит возврат из функции.

Теперь разбёремся в машинном коде:

Сначала инициализируются локальные переменные клиента.

Дескриптор файла сокета «sock» создается путём вызова системной функции _socket и передачи информации о протоколе, типе и домене через регистры edx, esi и edi соответственно.

Переменная server_address (в машинном коде «s») заполняется нулями (0x30) с помощью системного вызова _memset.

Потом настраивается адресная информация сервера.

Затем адрес переводится из текстового в двоичный формат с помощью системной функции _inet_pton. Обратите внимание, что, поскольку в коде явно не указан адрес, предполагается localhost (127.0.0.1).

Клиент подключается к серверу с помощью системного вызова _connect.

После подключения клиент отправляет строку helloClient на сервер.

Наконец, клиент получает ответ сервера в переменную value с помощью системного вызова _read.

Многопоточность

Наконец, мы рассмотрим основы потоков в C.

Во-первых, давайте посмотрим на код:

Как вы можете видеть, программа сначала печатает «This is before the thread», затем создаёт новый поток, который указывает на функцию *mythread(), используя функцию pthread_create(). По завершении функции *mythread() (после сна длиной в 1 секунду и вывода на экрана «Hello from mythread») новый поток присоединяется к основному потоку с помощью функции pthread_join() и выводится на экран «This is after the thread».

Теперь давайте разберём машинный код:

Сначала программа печатает «This is before the thread».

Затем создаётся новый поток с помощью системного вызова _pthread_create. Этот поток получает mythread() в качестве аргумента.

Как вы можете видеть, функция mythread() просто спит одну секунду перед выводом «Hello from mythread».

Примечание Внутри функции mythread() вы увидите два нопа. Они были специально размещены для облегчения навигации на этапе подготовки этой статьи.

После возврата из функции mythread() новый поток соединяется с основным потоком с помощью функции _pthread_join.

Наконец, на экран выводится «This is after the thread» и происходит возврат из функции.

Заключение

В статье мы рассмотрели массивы, указатели, динамическое распределение памяти, программирование сокетов (сетевое программирование) и многопоточность. Понимание этих аспектов существенно поможет вам продвинуться в изучении реверс-инжиниринга.

Чтобы вы смогли изучить Си с нуля, мы нашли интересный видеокурс на русском языке, подробно объясняющий основные конструкции и другие элементы языка. Автор видеоуроков в качестве рабочей среды использует ОС Ubuntu, компилятор GCC и редакторы кода Sublime Text и Visual Studio Code. Каждый видеоурок длится в среднем 25−30 минут, в течение которых подробно разбирается каждая тема. Курс ориентирован на тех, кто никогда не сталкивался с программированием.

Содержание курса

1. Введение в язык, создание первой программы
   Автор приводит историю языка, объясняет некоторые базовые понятия и создаёт простейшую программу на Си.
2. Переменные, создание переменных в языке Си
   В данном видео рассказывается о типах переменных (short, int, char, float, double, long, long long) и методах их создания.
3. Переменные, ввод и вывод информации в терминале в языке Си
   В видеоролике говорится о том, как ввести и вывести через терминал значения переменных с помощью функций scanf() и printf().
4. Escape-последовательности
   Escape-последовательности представляют собой сочетания символов, начинающиеся с косой черты и представляющие собой цифру или букву, например \n, \t. Автор рассказывает, какие escape-последовательности существуют, за что они отвечают и как используются в программе.
5. Арифметические операции
   Видео посвящено разбору различных арифметических операций, принятых в языке.
6. Составные операции в языке Си
   В Си можно использовать составное присваивание значений, например, с помощью +=, -=, *= и /=. В видео подробно разбираются эти конструкции, а также показывается их использование на примерах программ.
7. Локальные и глобальные переменные в языке Си
   Автор рассказывает о том, чем отличаются глобальные и локальные переменные, а также знакомит с ключевыми словами extern и static.
8. Преобразование типов данных в языке Си
   В видео объясняется, как привести переменные к другим типам данных, например int к float.
9. Массивы, создание массивов в языке Си
   Из видео вы узнаете, что такое массив, как его создать на языке Си и как выполнять действия с его элементами. Рассматривается только одномерный массив.
10. Многомерные массивы, создание многомерного массива в языке Си
    В видеоролике объясняется работа с многомерными массивами на примере двумерного.
11. Объявление констант
    В 11-м уроке автор рассказывает о том, что такое константа и как объявить её в коде.
12. Объявление перечислений в языке Си
    Автор знакомит с ключевым словом enum и рассказывает, как с его помощью создавать собственные типы данных с помощью последовательностей констант.
13. Отладка с помощью определений препроцессора
    Вы узнаете, какие существуют команды для препроцессора (компонента компилятора, подготавливающего код к компиляции), для чего нужна каждая из них и как применять команды на практике.
14. Сравнение значений в Си
    В видео рассказывается о сравнении значений переменных с помощью ==, !=, >, <, >=, <=.
15. Логические значения
    В данном видеоуроке рассматриваются логические операции И &&, ИЛИ || и НЕ !.
16. Проверка условий — тернарная операция
    Вы познакомитесь с тернарной операцией, которая представляет собой краткую запись if... else, например (a > b) ? a : b.
17. Проверка условий if-else
    В 17-м уроке рассматривается конструкция if... else, позволяющая запустить определённый код в зависимости от того, выполнено требуемое условие или нет.
18. Оператор множественного выбора switch case
    В видео рассмотрен оператор switch... case, с помощью которого в зависимости от поданного ключа можно выполнить нужный код.
19. Цикл for
    Автор рассказывает о цикле for, позволяющем выполнить код внутри цикла при необходимых условиях требуемое количество раз.
20. Циклы while, do while
    Цикл while часто используется для перебора элементов и может повторяться сколько угодно раз. Цикл do... while отличается от while блоком do, код в котором вне зависимости от условия выполнится хотя бы один раз.
21. Утверждения break, continue, goto
    Вы изучите работу с оператором выхода из цикла break, перехода на следующую итерацию цикла continue, а также оператором перехода на определённое место в коде goto.
22. Функции, прототипы функций
    Здесь даётся введение в функции. Чтобы облегчить понимание, в видео рассматриваются функции без передачи параметров и аргументов. Также вы узнаете, что такое прототип функции.
23. Функции, передача аргументов в функции
    В видеоуроке рассматривается передача аргументов в функции, а также возврат значений из функций.
24. Функции, рекурсия
    В видео рассказывается о рекурсии — вызове функции из самой себя.
25. Сравнение листингов кода на Си
    Вы узнаете, как с помощью команды терминала diff сравнить два файла с исходным кодом.
26. Пишем код на Си с разделением на файлы
    Вы научитесь разделять свою программу на несколько файлов с исходным кодом и использовать заголовочные файлы с расширением .h.
27. Указатели в языке Си
    В видеоуроке всё внимание уделяется указателям — переменным, содержащим ссылку на другую переменную.
28. Передача указателей в функции в языке Си
    С помощью указателей можно напрямую изменять элементы в памяти. Поэтому с их помощью расширяются возможности функций.
29. Массивы указателей в языке Си
    Тема урока — создание и использование массивов указателей.
30. Функции ввода и вывода строк в языке Си
    В этом видео автор рассказывает о вводе/выводе строк через терминал с использованием функций printf(), scanf(), fprintf(), fscanf(), gets(), puts(), fgets(), fputs().
31. Строки, функции: strcat, strncat в языке Си
    В видеоуроке разбираются функции объединения строк strcat() и strncat().
32. Строки, функции: strstr, strcmp в языке Си
    Здесь уделяется внимание функции поиска в строке strstr() и функции сравнения строк strcmp().
33. Строки, функции: atoi, sprintf, itoa в языке Си
    В видео рассматривается функция перевода из строки в число atoi() и функции перевода из числа в строку sprintf() и itoa().
34. Структуры в языке Си
    Автор объясняет, что такое структуры, а также как их создавать и объявлять.
35. Структуры в языке Си: объявление указателей в структуре
    В видеоуроке рассматривается использование указателей в структурах и объясняется, почему в структурах лучше оперировать указателями, чем массивами.
36. Структуры в языке Си: указатели на структуры
    Здесь рассказывается о том, что такое указатели на структуры, на что они действительно указывают, а также объясняется, для чего нужен оператор ->.
37. Работа с файлами в языке Си
    В данном видеоуроке рассматривается чтение из файла, запись в файл и создание файла на языке Си. В видео демонстрируются кроссплатформенные методы работы с файлами, однако действия с файлами можно проводить и с помощью системных функций Linux.
38. Работа с файлами в языке Си: функции fread, fwrite
    Вы познакомитесь с функцией чтения из файла fread() и функцией записи в файл fwrite().
39. Сообщения об ошибках
    Если при работе с файлами возникают ошибки, их можно обработать с помощью функций perror() и strerror().
40. Рандомные числа в Си
    В видео автор разбирает создание псевдослучайных чисел с помощью функций srand(time(NULL)) и rand() и изменение границ множества случайных чисел.
41. Сортировка в Си
    В данном видеоуроке рассматривается использование быстрой сортировки qsort()(Quick Sort), уже встроенной в язык.
42. WinAPI
    В последнем видео курса вы изучите несколько базовых функций системной библиотеки WinAPI, с помощью которых вы сможете реализовать MessageBox.

Дополнительные материалы

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

Если видеоуроки не подходят для вас, вы можете ознакомиться с подборкой книг по языку Си и найти для себя подходящую. После изучения основ языка Си вы можете заглянуть в наш раздел с материалами по Си и смежным темам.

Теория: память приложений

При выполнении приложения загружаются в память. Но как мы все знаем, компьютеры имеют ограниченное количество памяти, и приложению нужно быть очень осторожным, чтобы не перезаписать область в памяти, принадлежащую другому приложению. Для того, чтобы избежать такой ситуации, используется так называемая виртуальная память, которую можно прекрасно описать с помощью сцены из сериала, выпущенного в начале 2000-х — Дрейк и Джош, в котором главные герои раскладывают суши по контейнерам:

В этой сцене Дрейк и Джош получили работу, в которой суши идут по конвейеру, и их нужно разложить по контейнерам. Более того, несмотря на то, что контейнеры выглядят одинаково, в одном контейнере должен быть только один тип суши.

Прим. перев. Посмотреть серию можно здесь, сцена с суши на 18 минуте.

Давайте перейдём от аналогии к концепции виртуальной памяти.

Конвейер с суши: как уже говорилось ранее, компьютеры имеют ограниченную память и должны быть очень осторожны и точны при записи данных, чтобы не перезаписать память других приложений. Хоть компьютер и может просто записать приложение в физическую память, в конечном итоге это приведёт к проблемам, так как фрагменты приложений быстро заполнят всю свободную память. В примере выше индивидуальные сушинки можно рассматривать как фрагменты приложения или часть памяти, занятой определённым приложением, а набор суши из шести штук — само приложение.

Дрейк и Джош: чтобы обойти проблему с заполнением конвейера одиночными сушинками, главные герои разбирают их по разным контейнерам, которые потом отправляют дальше по конвейеру. Ваш компьютер, как Дрейк и Джош, распределяет приложения по контейнерам, называемым виртуальным адресным пространством. Такие виртуальные адресные пространства позволяют приложению считать, что оно имеет полный контроль над всей памятью устройства. Однако когда приложение пытается получить доступ к памяти вне своего виртуального адресного пространства, маленькая, но чрезвычайно важная часть вашего ЦПУ — блок управления памятью — перенаправляет обращение к физической памяти в соответствии с выделенной областью для этого приложения, облегчая таким образом любую работу с памятью. Такое распределение позволяет компьютеру организовать работу сразу нескольких приложений через справочную таблицу с требованиями в виде динамической памяти.

ASCII-диаграмма работы виртуальной памяти

Также важно знать, что код всех приложений содержится внутри их виртуального адресного пространства. Приложения часто используют динамически подключаемые библиотеки (DLL), такие как libc или kernel32. DLL — внешние (т. е. не хранятся в исполняемом файле запускаемого приложения) системные или специально написанные библиотеки, которыми пользуется приложение. Пример представлен ниже.

Как вы видите, нигде в этой шестистрочной программе не объявляется printf(). Однако эта программа всё равно запустится без ошибок и выведет «Hello World». Это потому, что функция printf() — системная функция, определённая в libc, стандартной библиотеке C. Во время компиляции libc внешне подключается к исполняемому файлу. В системах Linux можно посмотреть используемые программой библиотеки с помощью команды ldd.

Отображение используемых программой библиотек с помощью ldd

Если вы смотрите на скриншот выше и думаете, что такое 0xb7e99000, то это адрес библиотеки libc в памяти. Адреса в памяти представлены в шестнадцатеричном формате. Более подробно о шестнадцатеричном формате вы можете узнать здесь.

Теория: стек

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

Боб — мойщик посуды в модном ресторане. Каждый вечер у Боба есть стопка тарелок, которые нужно вымыть. Более того, в течение ночи на верх стопки могут добавляться ещё тарелки, по мере уборки столов. Если Боб возьмёт тарелку откуда-то ещё кроме как сверху стопки, то вся стопка развалится и тарелки разобьются.

А теперь вместо Боба и стопки тарелок представьте компьютер и стопку объектов с данными. Когда что-то добавляется (push) в стек, оно кладётся наверх стопки. Когда извлекается (pull), то берётся сверху стопки. Так работает механизм LIFO (Last In First Out, последним пришёл — первым вышел).

Стек используется программами для хранения различных вещей, например, указателей на функции и переменных.

Теория: вызов функций и возвраты

Посмотрите на код, представленный ниже:

В этом фрагменте кода мы видим что функция add() принимает два аргумента целочисленного типа, имена которых А и В. В функции main() мы вызываем функцию add() с 1 в качестве аргумента А и 2 — В. Если перевести это в машинный код:

Как вы видите, при вызове функции с параметрами программа сначала добавляет оба параметра в стек, а затем выполняет команду call. Команда call перенаправляет указатель инструкции программы по адресу вызываемой функции. Указатель программы подобен маленькому карандашу, который вы используете для отслеживания слов при чтении. Указатель инструкции всегда указывает на ту инструкцию, которая должна быть выполнена (слово, которое будет прочитано). Однако, перед тем, как перейти к вызываемой функции, команда call помещает адрес следующей за ним инструкции в стек, чтобы, когда произойдёт возврат из функции add(), было известно, с чего продолжать выполнение программы. Адрес места, в которое функция должна вернуться, называется указателем возврата функции.

Атака: переполнение буфера стека

Прежде чем углубляться в технические подробности о том, что такое переполнение стекового буфера и как оно работает, давайте рассмотрим простую для понимания аналогию:

Алиса и Боб раньше встречались, но в итоге Алиса рассталась с Бобом. Время шло, Алиса оставила прошлое позади, но Бобу так и не удалось справиться с горем. Теперь Алиса выходит замуж за Роберта Хакермана, заклятого врага Боба. Боб, будучи жутким чудаком, следил за всеми свадебными планами Алисы благодаря своему секретному доступу к электронной почте Алисы. Боб увидел, что Алиса наняла известного дизайнера свадебных тортов, который хотел, чтобы Алиса отредактировала части своего рецепта под свои вкусовые предпочтения. Дизайнер дал Алисе рекомендованный список ингредиентов, которые можно добавить, но сказал, что сделает всё в точности, как она захочет. Боб открыл документ, прикреплённый к электронному письму дизайнера, и увидел, что меняемые строки рецепта выглядят так:... Затем мы наделим глазурь вкусом, добавив _____. После этого мы добавим немного шоколада ...Боб заметил, что если ввести «банан» в строку, текст будет выглядеть так:... Затем мы наделим глазурь вкусом, добавив банан. После этого мы добавим немного шоколада ...Но если Боб введёт «клубника» в строку, текст будет выглядеть так:... Затем мы наделим глазурь вкусом, добавив клубникуосле этого мы добавим немного шоколада ...Боб понял, что это будет идеальный способ испортить свадьбу Алисы, и всё, что ему нужно было сделать, это переписать остальную часть рецепта своей собственной отвратительной версией! В день свадьбы Алисы дизайнер наконец-то показал торт, который он сделал — он был покрыт жуками и сделан из замороженного майонеза!

Переполнение буфера стека, как и атака Боба, перезаписывает данные, которые разработчик не собирался перезаписывать, обеспечивая полный контроль над программой и её выходными данными.

Итак, теперь давайте посмотрим на это в реальном мире. Взгляните на следующий фрагмент кода:

В приведённой выше функции мы видим, что массив символьного типа с именем buffer создаётся с размером 64. Затем мы видим, что переменная modified равна 0, и функция gets() вызывается с переменной buffer в качестве аргумента. Наконец, мы видим оператор IF, который проверяет, не равно ли значение modified нулю. Очевидно, что нет, где в этом приложении переменная modified имеет значение, отличное от 0. Так как мы собираемся её изменить?

Что ж, давайте сначала посмотрим на документацию функции gets():

Определение функции gets()

Описание багов в функции gets()

Как видите, функция gets() просто принимает пользовательский ввод. Однако функция не проверяет, действительно ли пользовательский ввод вписывается в структуру данных, в которой мы его храним (в данном случае это buffer), и, таким образом, мы можем переполнить структуру данных и повлиять на другие переменные и данные стека. Кроме того, поскольку мы знаем, что все переменные хранятся в стеке, и мы знаем, что представляет собой переменная modified (0), всё, что нам нужно сделать, — это ввести достаточно данных, чтобы перезаписать переменную modified. Давайте посмотрим на диаграмму:

ASCII-диаграмма переполнения буфера стека

Как видите, если злоумышленник просто вводит слишком много текста, он может перезаписать переменную modified и всё остальное в стеке, включая указатели возврата. Это означает, что если злоумышленник сможет взять под контроль стек программы, он сможет эффективно контролировать всю программу и заставить её делать то, что он хочет. Например, можно просто перезаписать указатель возврата функции в стеке на пользовательский, указывающий на вредоносную функцию.

Атака: ret2libc

Как мы знаем из первого раздела, libc — это стандартная библиотека языка C. Это означает, что она содержит все общие системные функции, включённые в язык программирования C. Теперь, что если злоумышленник сможет взять под контроль программу для выполнения некоторых из этих функций?

Это и есть ret2libc. Одной идеальной аналогией для последствий ret2libc может быть серия Матрицы. Вспомните классическую сцену «Оружие, много оружия». Оператор Танк смог полностью обойти и перепрограммировать матрицу, чтобы МОРЕ оружия просто появилось из ниоткуда.

Вы можете думать о возврате в libc вот так: мы можем взять под контроль матрицу (стандартную библиотеку C) и заставить её делать то, что мы хотим.

По сути, атаки ret2libc фактически основаны на переполнении стекового буфера. Вспомните, что было сказано в конце предыдущего раздела: если злоумышленник может перезаписывать данные в стеке, он может просто перезаписать указатель возврата, чтобы указать на конкретную функцию в libc, и передать ей любые аргументы, необходимые для доставки полезной нагрузки.

Одной из самых распространённых функций для атак ret2libc является функция system(). Давайте посмотрим на документацию:

Документация по функции system()

Как видите, функция system() просто выполняет shell-команды (shell — это командная строка Linux). Более того, если мы прочитаем описание, то увидим, что система просто выполняет /bin/sh -c <команда>, и команда передаётся в функцию через аргумент.

Итак, всё, что нам нужно сделать, чтобы получить доступ из командной строки к компьютеру, на котором запущено уязвимое приложение, — это вставить «/bin/sh» в стек в качестве аргумента, а затем заменить указатель возврата или вызова адресом памяти функции system(), так чтобы эта функция вызывалась с /bin/sh в качестве аргумента, запускала оболочку и предоставляла нам полный доступ через систему.

Как видите, эксплуатация даже такой, казалось бы простой уязвимости, может привести к катастрофическим последствиям для машины, где находится уязвимый файл. В следующем материале будут описаны другие уязвимости и способы защиты от них.

С++

Разработчики добавили в IDE поддержку экспериментального языкового движка, основанного на clangd, в дополнение к основному. Он включен по умолчанию на macOS и Linux, а в Windows-версии его необходимо активировать вручную в настройках. Экспериментальная функция используется только для показа ошибок и предупреждений в редакторе, а настроить их под себя можно в окне Clangd:

Разобраться с тем, как работает новый движок, можно в блоге компании.

Кроме того, в обновлении появилось обновленное инспектирование кода, которое определяет аргументы одного типа, идущие в неправильном порядке. Оно требует выразительных имен параметров, а также включенного экспериментального движка. Инспектирование полагается на несколько эвристических алгоритмов.

Новые проектные модели

Ранее, утверждают разработчики, написанные не с использованием CMake проекты получали ограниченную функциональность CLion. Теперь IDE полностью поддерживает как проекты на Gradle C++, так и базы данных компиляции. Чтобы открыть проект, необходимо:

• открыть файл build.gradle из исходников проекта, написанного с использованием новых плагинов Gradle C++;
• использовать файл compile_commands.json из базы данных компиляции.

Также они не забыли и про CMake. Обновление принесло возможность не записывать заголовочные файлы напрямую, чтобы довольствоваться всеми возможностями понимания кода. Если добавить заголовочный или исходный файл в любой проект, среда разработки автоматически сделает его файлом проекта:

Новые инструменты

Улучшение получил динамический анализатор кода Valgrind Memcheck, добавленный в 2017.3. Создатели IDE сделали возможным импорт/экспорт результатов анализа из CLion.

В дополнение к Valgrind среда разработки получила поддержку Google Sanitizers. Для их включения требуется флаг сборки -fsanitize, который нужно ввести вручную. CLion с Clang версии выше 3.8.0 и GCC выше 5.0.0 затем автоматически распознает флаг и покажет результаты анализа Google Sanitizers в отдельной вкладке:

С полным списком поддерживаемых Sanitizers и их настройками можно ознакомиться в блоге JetBrains.

Более того, разработчики послушали пользователей Твиттера и включили полную поддержку инструментов баз данных и SQL в виде плагина. Среди поддерживаемых БД есть такие, как MySQL, PostgreSQL, Oracle, DB2 и Sybase.

Отладчик

CLion 2018.2 «из коробки» поддерживает такие инструменты отладки, как LLDB 6.0 на macOS и Linux, а также GDB 8.1 на Linux и Windows и GDB 8.0.1 — на macOS.

Теперь IDE использует «украшатели» типа для отображения указателей этого типа при работе с GDB, а LLDB правильно обрабатывает unsigned char и unordered_map.

Другие улучшения

Clion 2018.2 также получила множество мелких улучшений и обновлений, среди которых перекомпиляция единственного файла для ускорения процессов разработки, поддержка Touch Bar новых MacBook, а также создание процессора, запускающего форматирование только лексем языка для улучшения работы интерфейса, и многое другое. По традиции разработчики из JetBrains опубликовали видеоролик, рассказывающий об обновлении:

Подробнее обо всех улучшениях и исправлениях можно узнать на официальной странице обновления.

Предыдущая крупная версия IDE под номером 2018.1 вышла в марте 2018 года. В нее была добавлена поддержка WSL и CMake Install.

C++17

Компания экспериментирует с альтернативами для языкового движка CLion и планирует выпустить первые результаты в последующих версиях в 2018 году. Тем не менее, в настоящее время последние улучшения коснулись текущей версии:

• поддержка декомпозиции при объявлении (структурированные привязки);
• инициализаторы if и switch стандарта C++17;
• полноценная поддержка тернарного оператора;
• переработаны рефакторинги Rename и Change Signature для случая наследования:

Редактор в целом стал более отзывчивым благодаря существенным изменениям обработчиков ввода и инкрементальной подсветке.

Clang-Tidy

Мощный инструмент, дополняющий собственный анализатор CLion. Разработчики добавили возможности увеличения его влияния. Теперь можно прописывать опции для некоторых проверок, например, modernize-use-nullptr. Также появилась возможность указать .clang-tidy в качестве файла конфигурации CLion вместо стандартного. Это означает, что вся команда может теперь использовать единый набор правил Clang-Tidy независимо от пользовательских настроек IDE и редакторов.

Помимо этого обновлен и оптимизирован набор проверок Clang-Tidy по умолчанию.

WSL

Поддержка компилятора Microsoft Visual C++ теперь включена по умолчанию. Также расширен набор инструментов на Windows за счет поддержки слоя WSL, позволяющего компилировать, запускать и отлаживать исполняемые файлы сборок Linux. CLion будет использовать компиляторы CMake, make, GCC/G++ и отладчик WSL для сборки и запуска.

Поддержка WSL содержит выпущенный ранее анализатор кода Valgrind Memcheck для выявления ошибок, связанных с памятью:

Руководство по установке и конфигурации WSL доступно для ознакомления в блоге компании.

По словам разработчиков, WSL является первым шагом к поддержке удаленного доступа в CLion, поэтому в его реализации использован SSH.

CMake

Начат процесс отсоединения проектной модели CMake от CLion. Для случая, когда нужно просто прочитать сторонний код на C++ в CLion, появилась возможность открывать один файл или каталог без задействования CMake. Тем не менее, CLion все еще нуждается в модели CMake для предоставления умных фич IDE. Интеграция самой CMake продолжается, в связи с чем в редакторе появилось действие CMake Install во вкладке Run, доступное также для добавления в качестве шага в конфигурации запуска:

Командой Create new file (Alt+Insert) можно создать файл CMakeLists.txt, содержимое которого определяется шаблоном в настройках редактора.

Редактор

Команда разработчиков время от времени использует CLion в собственных нуждах, что позволяет ощущать необходимость некоторых косметических улучшений:

• «Сухарики» («breadcrumbs») для C/C++ — маленькие маркеры в нижней части редактора, облегчающие навигацию по коду, отображая текущие пространства имен, классы, структуры, функции и лямбда-выражения:
  

• Удаление конструкций — безопасное удаление if, else, for, while, do..while и for, а также удаление частей вложенных операторов:
  

• Свертка управляющих операторов — одна из самых востребованных функций. Сочетанием Shift+Ctrl+Period / Ctrl+= (Windows / Linux) или ⇧⌘. / ⌘+ (macOS) можно сворачивать тела if / else, do / while, for и switch), а также операторы целиком.
• Настройки окна сообщений — дополнительные опции позволяют задать тип выводимых сообщений в логе.

Также стоит упомянуть Project Scopes — возможность изучить проект с разных углов, используя как предопределенные режимы Project Source Files, Project Non-Source Files и Changed files, так и задавая свои режимы просмотра.

VCS

В интерфейсе CLion появились частичные коммиты (git add -p), позволяют зафиксировать лишь часть изменений проекта. Выделив участки кода для коммита, нужно снять соответствующие галочки в диалоговом окне. Также доступна возможность перемещать изменения между списками прямо из редактора.

Больше информации об этой функциональности доступно в блоге компании.

Rust, Fortran и Objective-C/C++

CLion 2018.1 включает поддержку Objective-C and Objective-C++. Также стали доступны обновленные плагины для Rust и Fortran. Плагин Rust содержит отладчик и менеджер пакетов Cargo, добавленный благодаря отсоединению проектной модели CMake. Плагин Fortran работает посредством CMake и поддерживает FORTRAN 77, Fortran 90, Fortran 95, Fortran 2003 и Fortran 2008. Подробнее о плагинах можно прочитать в блоге JetBrains.

С другими изменениями можно ознакомиться в традиционном кратком видео-обзоре:

Более подробный список нововведений доступен на официальной странице обновления.

Своего рода элегия по C

Я влюбился в язык программирования C около 24-ёх лет назад. Я выучил основы, прочитав испанский перевод второго издания «Языка программирования C» Кернигана/Ритчи (K&R). До этого я писал на Turbo Pascal в довольно низкоуровневой манере — с указателями и ручным выделением памяти. После него C казался освежающим и мощным.

К&R — это отличная книга благодаря стилю изложения и лаконичности программирования. Эта книга даже учит, как реализовать простые функции malloc/free, что крайне поучительно. Даже такие низкоуровневые конструкции, которые выглядят как часть языка, могут быть реализованы на самом языке!

В последующие годы я хорошо освоил C. Это простой язык с небольшой стандартной библиотекой. Наверное, это был идеальный язык для реализации ядер Unix в 20 000 строк кода или около того.

GIMP и GTK+ научили меня тому, как использовать модный объектно-ориентированный подход в C. GNOME показал, как поддерживать крупномасштабные проекты, написанные на C. Стало казаться, что 20 000 строк C кода — это проект, который можно практически полностью понять за пару недель.

Но наши кодовые базы уже далеко не такие маленькие. Сейчас в процессе разработки программного обеспечения огромные надежды возлагаются на функции, доступные в стандартной библиотеке языка.

Опыт использования C

Положительный

• Чтение исходного кода проекта POV-Ray впервые и изучение того, как использовать объектно-ориентированный подход и наследование в чистом C;
• Чтение исходного кода проекта GTK+ и изучение читаемого, поддерживаемого и чистого стиля написания кода на C;
• Чтение исходного кода проекта SIOD, а также ранних исходников проекта Guile и понимание того, как интерпретатор Scheme может быть написан на C;
• Написание первых версий Eye of Gnome и доработка системы микротайлового рендеринга.

Негативный

• Работа в команде Evolution, когда программа постоянно падала. Мы были вынуждены приобрести машину с Solaris на борту, чтобы иметь возможность купить Purify; в те времена Valgrind-а еще не существовало;
• Отладка взаимных блокировок потоков в gnome-vfs;
• Безуспешная отладка Mesa;
• Когда мне передали исходники первых версий Nautilus-share, я увидел, что free() вообще не используется;
• Попытки рефакторинга кода, о стратегии управления памятью которого я не имел понятия;
• Попытка сделать библиотеку из кода, кишащего глобальными переменными, и в котором ни одна функция не помечена как static.

Фичи Rust, которых не хватает в C

Автоматическое управление ресурсами

Один из первых блог-постов, которые я прочитал о Rust, назывался «В Rust вам никогда не придётся закрывать сокет». Rust заимствует у C++ идеи об идиоме RAII (Resource Acquisition Is Initialization, получение ресурса есть инициализация) и умных указателях, добавляет принцип единоличного владения для значений и предоставляет механизм автоматического, детерминированного управления ресурсами в очень изящной упаковке.

• Автоматическое: не нужно вызывать free() вручную. Память освободится, файлы закроются, мьютексы разблокируются, когда переменные выйдут из зоны видимости. Если вам нужно написать обёртку для стороннего ресурса, то всё, что нужно сделать, это реализовать типаж Drop. Обёрнутый ресурс ощущается как часть языка, потому что вам не приходится нянчиться с его временем жизни вручную;
• Детерминированное: ресурсы создаются (память выделяется и инициализируется, файлы открываются и т. д.) и уничтожаются, когда выходят из зоны видимости. Никакой сборки мусора: ресурсы действительно освобождаются, когда вы закрываете скобку. Вы начинаете видеть время жизни данных в своей программе как дерево вызовов функций.

После того, как постоянно забываешь освобождать/закрывать/уничтожать объекты в C, или, ещё хуже, пытаешься понять, где в чужом коде забыли сделать что-то из этого (или ошибочно сделали дважды)… я просто больше этого не хочу.

Дженерики

Vec<T> — это действительно вектор, размер элементов которого равен размеру объекта типа T. Это не массив указателей на объекты, память для которых выделялась отдельно. Он специально компилируется в код, который может работать только с объектами типа T.

После написания большого количества сомнительных макросов на C, чтобы сделать что-то похожее… я больше этого не хочу.

Типажи — это больше, чем просто интерфейсы

Rust — это не Java-подобный объектно-ориентированный язык, подробнее об этом можно прочитать в open-source книге «The Rust Programming Language». Вместо этого в нём есть типажи, которые поначалу похожи на интерфейсы в Java, — простой способ осуществления динамического переключения (dynamic dispatch), так что если объект реализует Drawable, то можно предположить, что у него есть метод draw().

Однако типажи — это более мощный инструмент. Одной из отличительных особенностей типажей можно считать ассоциированные типы (associated types). Например, Rust предоставляет типаж Iterator, который вы можете реализовать:

Это означает, что всякий раз, когда вы реализуете этот типаж для какого-либо объекта, поддерживающего итерирование, вы также указываете тип Item для значений, которые он выдаёт. Если вы вызываете next() и элементы ещё остались, вы получите Some(ТипВашегоЭлемента). Когда у вашего итератора закончатся элементы, он вернет None.

Ассоциированные типы могут ссылаться на другие типажи.

Например, в Rust вы можете использовать циклы for со всем, что реализует типаж IntoIterator:

Когда реализуете этот типаж, вы должны указать и тип элементов, которые будет выдавать ваш итератор, и сам тип IntoIter, который реализует типаж Iterator и хранит состояние вашего итератора.

Таким образом, вы можете построить настоящую сеть типов, которые ссылаются друг на друга. Вы можете написать типаж, который говорит: «Я могу сделать foo и bar, но только если вы дадите мне тип, который умеет делать вот это и это».

Срезы

Я уже писал о том, насколько в C не хватает срезов (slices) для работы со строками и какая это головная боль, когда привык, что они под рукой.

Современные инструменты для управления зависимостями

Вместо того, чтобы

• Запускать pkg-config руками или через Autotools-макрос;
• Сражаться с include-путями в заголовочных файлах…
• … и библиотечных файлах;
• И, по сути, полагаться на то, что пользователь гарантирует установку верных версий библиотек,

вы пишете файл Cargo.toml, в котором перечисляются названия и версии всех наших зависимостей. Они будут загружены из общеизвестного источника или из любого другого, указанного вами.

Не нужно сражаться с зависимостями. Оно просто работает, когда вы набираете cargo build.

Тесты

В C очень сложно покрывать код тестами по нескольким причинам:

• Внутренние функции часто помечены как static. Это означает, что они не могут быть вызваны вне файла, в котором эта функция определена. Тестовая программа вынуждена либо #include-ить содержимое исходника, в котором функция объявлена, либо использовать #ifdef, чтобы убирать static только при тестировании;
• Вам придётся плясать с бубном вокруг вашего Makefile, чтобы слинковать тестовую программу с определённой частью зависимостей основной или с какой-то частью оставшейся программы;
• Вам придётся выбрать фреймворк для тестирования. Вам придётся зарегистрировать свои тесты в фреймворке для тестирования. Вам придётся изучить этот фреймворк.

В Rust вы пишете

в любом месте программы или библиотеки, и, когда вы набираете cargo test, ОНО ПРОСТО, *****, РАБОТАЕТ. Этот код линкуется только в тестовый исполняемый файл. Не нужно ничего компилировать дважды вручную, писать Makefile-магию или разбираться, как вытащить внутренние функции для тестирования.

Для меня это одна из главных киллер-фич языка.

Документация с тестами

Rust генерирует документацию на основе комментариев, размеченных с помощью Markdown. Код из документации запускается как обычные тесты. Вы можете показывать, как функция должна использоваться, одновременно тестируя её:

Код из примера запускается как тест, чтобы убедиться, что ваша документация своевременно обновляется вместе с кодом программы.

Гигиеничные макросы

В Rust особые гигиеничные макросы, позволяющие избежать проблем, при которых во время разворачивания C макросов происходит непреднамеренное затенение идентификаторов в коде. Вам больше не нужно писать макросы, заключая все символы в скобки, чтобы max(5 + 3, 4) работал правильно.

Никакого неявного приведения типов

Все эти баги, которые появляются в C из-за непреднамеренного приведения int к short или к char и т. п. — в Rust их нет. Вы должны приводить типы явно.

Никакого целочисленного переполнения

Этим всё сказано.

Как правило, никакого неопределённого поведения в безопасном режиме

В Rust, если что-то вызывает неопределенное поведение в «безопасном режиме» (всё, что написано вне блоков unsafe {}), это расценивается как баг самого языка. Например, можно сделать побитовый сдвиг отрицательного целого числа вправо и произойдёт именно то, что вы ожидаете.

Сопоставление с образцом

Знаете, как gcc выдает предупреждение, если вы используете switch() с перечислением (enum), но обработаете не все варианты? Это детский сад по сравнению с Rust.

В Rust в различных местах используется сопоставление с образцом. Он умеет делать эту штуку с перечислениями в match-выражении. Он поддерживает деструктурирование, а это значит, что можно возвращать несколько значений из функции:

match работает на строках. ВЫ МОЖЕТЕ МАТЧИТЬ ГРЁБАНЫЕ СТРОКИ.

Вы же знаете, насколько такое плохо читается?

my_func(true, false, false)

Как насчет того, чтобы вместо этого использовать сопоставление с образцом на аргументах функции:

Стандартная полезная обработка ошибок

Я подробно останавливался на этом. Больше никаких булевых возвращаемых значений без нормального описания ошибки, никаких случайно проигнорированных ошибок, никакой обработки исключительных ситуаций longjmp-ами.

#[derive(Debug)]

Если вы пишете новый тип (скажем, структуру с кучей полей), то можно написать #[derive(Debug)], и Rust будет знать, как автоматически напечатать содержимое этого типа для отладки. Больше не нужно руками писать специальную функцию, которую затем придётся вызывать из gdb, только для того, чтобы посмотреть содержимое полей пользовательского типа.

Замыкания

Вам больше не придётся передавать указатели на функцию и user_data вручную.

Заключение

Я пока не попробовал «fearless concurrency», где компилятор может предотвращать гонки данных в многопоточном коде. Я полагаю, что это в корне меняет положение дел для людей, которые пишут параллельный код на регулярной основе.

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

Rust непросто освоить, но я уверен, что это того стоит. Сложность в том, что язык требует от вас глубокого понимания кода, который вы хотите написать. Я думаю, что это один из тех языков, которые делают вас лучше как программиста и позволяют решать более амбициозные проблемы.

Результаты

Согласно проведённому опросу, список самых популярных сред разработки выглядит следующим образом:

Второе место занимает обычный текстовый редактор Vim. Его пользователи предпочитают «прикручивать» к программе разные расширения для работы с конкретными языками.

К «другим» отнесены программы, за которые проголосовало менее 1 % разработчиков. Самыми примечательными представителями этой группы исследователь называет некогда востребованный C++Builder, а также CodeLite и NetBeans, которые попали в этот список наравне с редакторами Atom и Notepad++.

Оценка количества разработчиков

Отправной точкой этого исследования послужило примерное число разработчиков ПО в мире. По данным Evans Data, в 2017 году их было 22 миллиона человек в 40 странах мира.

Согласно индексу TIOBE, приблизительное число программистов на C/C++ составляет около 3,5 миллионов человек. По словам старшего менеджера Microsoft Бенжамина Сюэ (Benjamin Xue), в 2016 году более 1,5 миллионов разработчиков писали на C++ в Visual Studio. JetBrains говорит, что в 2015 году на C и C++ писало более 6 миллионов человек. А опрос Дэвида Копполы дополнил картину, и исследователь пришёл к цифре в 5,1 миллиона разработчиков, пишущих на C/C++, по всему миру.

Исходя из этих вычислений, автор исследования определил примерное число кодеров, использующих каждую из 5 самых востребованных сред разработки:

Всего в опросе Копполы приняли участие 1860 человек, 87 % из которых — пользователи Reddit. Статистическая погрешность полученных значений составляет около 2,99 % с доверительным интервалом 99 %.

Языки C/C++ весьма популярны. При этом они входят в список самых нелюбимых инструментов для разработки по версии CodinGame.

+ 1,69 % за год — не такая уж внушительная цифра для языка года, так что, по мнению аналитиков TIOBE, языку Си удалось победить только за счет отсутствия выдающихся конкурентов. Следом за ним успешно растут рейтинги Python (+ 1,21 %) и Erlang (+ 0,98 %).

Эксперты утверждают, что такой подъем весьма примечателен для Си, особенно после резкого падения интереса к нему в 2015 году. Три года назад он обладал рейтингом в 17 %, а за последующие 18 месяцев успел потерять целых 10 %. Вероятной причиной «возрождения» аналитики называют его огромную популярность в сферах производства и машиностроения.

Примечательные «скачки» популярности 2017 года принадлежат языкам R (переместившемуся с 16 на 8 место), Erlang (с 44 на 23) и Kotlin (с 89 на 39). Подающими надежды языками TIOBE назвал Julia, Hack, Rust и Kotlin, которым в ушедшем году так и не удалось войти даже в тридцатку лучших.

Напомним, что TIOBE отслеживает статистику поисковых запросов по языкам программирования и в начале каждого месяца представляет визуализированные интерактивные рейтинги самых популярных из них.

Прим. перев. Макросы в таких языках, как Lisp, Scala и Rust, во многом лишены тех проблем и недостатков, которые описаны в этой статье.

Макросы и функции

При первом знакомстве макросы могут показаться обычными вызовами функций. Конечно, у них немного странный синтаксис, но они «ведут себя» как обычные функции. Тогда в чём разница?

Макрос можно условно назвать функцией обработки и замены программного кода: после сборки программы макросы заменяются макроопределениями. Вот как это выглядит:

Этот код преобразуется в следующий:

При вызове же функции под неё выделяется новый стековый кадр, и она выполняется самостоятельно и не зависит от места в коде, откуда была вызвана. Таким образом, переменные с одинаковыми именами в разных функциях не вызовут ошибку, даже если вызывать одну функцию из другой.

Но если попытаться проделать такой же трюк с помощью макроса, то во время компиляции будет выброшена ошибка, так как обе переменные в итоге будут находиться в одной функции:

Более того, функции выполняют проверку типов: если функция ожидает на входе строку, а получает число, будет выброшена ошибка (или, по крайней мере, предупреждение, в зависимости от компилятора). Макросы в то же время просто заменяют аргумент, который им передан.

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

Прим. перев. Чтобы не переходить к определению каждого макроса, можно попросить компилятор раскрыть макросы — это можно сделать с помощью команды gcc -E source.c. Имейте в виду, что если вы включаете в свой код с помощью #include стандартные заголовочные файлы, после препроцессинга в коде может оказаться много тысяч строк, так что стоит перенаправить вывод компилятора в файл.

Тем не менее, можно выделить одно явное преимущество макросов перед функциями — производительность. Макрос быстрее, чем функция. Как уже упоминалось выше, под функцию выделяются дополнительные ресурсы, которые можно сэкономить, если использовать макросы. Это преимущество может сыграть весомую роль в системах с ограниченными ресурсами (например, в очень старых микроконтроллерах). Но даже в современных системах программисты производят оптимизации, используя макросы для небольших процедур.

Прим. перев. Интересный подход к оптимизации использования ресурсов в программе на Си рассмотрен в другой нашей статье.

В C99 и C++ существует альтернатива макросам — встраиваемые (inline) функции. Если добавить ключевое слово inline перед функцией, компилятору будет дано указание включить тело функции в место её вызова (по аналогии с макросом). При этом встраиваемые функции могут быть отлажены, и у них есть проверка типов.

Однако ключевое слово inline — это просто подсказка для компилятора, а не строгое правило, и компилятор может проигнорировать эту подсказку. Чтобы этого не произошло, в gcc есть атрибут always_inline, который заставляет компилятор встроить функцию.

Встраиваемые функции — отличная штука, которая, как может показаться, делает использование макросов нецелесообразным. Однако это не совсем так.

Когда использовать макросы в Cи

Передача аргументов по умолчанию

В C++ есть весьма удобный инструмент, которого нет в Си, — аргументы по умолчанию:

В Си задача опциональных аргументов может быть решена с помощью макросов:

Этот код довольно безопасен и не скрывает никаких подводных камней (их мы обсудим далее). Конечно, эту задачу можно также решить с помощью функции, но она достаточно тривиальна, чтобы нести накладные расходы при использовании функций. Макрос справляется с ней на ура.

Использование отладочных строк

Некоторые компиляторы предопределяют макросы, которые нельзя использовать в функциях: __FILE__, __LINE__, __func__.

Их можно включать в определения макросов, используемых для отладки:

В итоге получается интересный способ ведения логов.

Модификация синтаксиса

Это очень мощная особенность макросов. Используя её, можно создать свой собственный синтаксис.

Например, в Cи нет конструкции foreach. Но её можно создать через макрос:

В этой вставке кода определена структура, содержащая связный список. Предполагая, что его узлы заполнены, можно пройтись по нему с помощью LIST_FOREACH так же, как и при использовании foreach в современных языках.

Эта техника действительно очень эффективна и при правильном использовании может дать довольно хорошие результаты.

Другие типы макросов

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

• #include — включить содержимое стороннего файла в текущий файл,
• #ifdef — задать условие для компиляции,
• #define — определить константу (и, конечно же, макрос).

#ifdef играет ключевую роль при создании заголовочных файлов. Использование этого макроса гарантирует, что заголовочный файл включён только один раз:

Стоит отметить, что основное предназначение #ifdef — условная компиляция блоков кода на основе некоторого условия. Например, вывод отладочной информации только в режиме отладки:

Прим. перев. С помощью #ifdef также довольно часто задаётся условие для компиляции на различных версиях ОС и архитектурах: #ifdef _WIN32, #ifdef _WIN64, #ifdef __linux__ и так далее.

Как правило, для определения констант используется #define, но в некоторых проектах его заменяют на const и перечисления (enum). Однако при использовании любой из этих альтернатив есть свои преимущества и недостатки.

Использование ключевого слова const, в отличие от макроподстановки, позволяет произвести проверку типов данных. Но в Cи это создаёт не совсем полноценные константы. Например, их нельзя использовать в операторе switch-case и для определения размера массива.

Прим. автора В C++ переменные, определённые ключевым словом const, являются полноценными константами (их можно использовать в приведённых выше случаях), и настоятельно рекомендуется использовать именно их, а не #define.

Перечисления в то же время — полноценные константы. Они могут использоваться в операторах switch-case и для определения размера массива. Однако их недостаток заключается в том, что в перечислениях можно использовать только целые числа. Их нельзя использовать для строковых констант и констант с плавающей запятой.
Вот почему использование #define — оптимальный вариант, если нужно достичь единообразия в определении различного рода констант.

Таким образом, у макросов есть свои преимущества. Но использовать их нужно весьма аккуратно.

Подводные камни при использовании макросов

Отсутствие скобок

Наиболее распространённая ошибка, которую допускают при использовании макросов, — отсутствие скобок вокруг аргументов в определениях макросов. Поскольку макросы подставляются непосредственно в код, это может вызвать неприятные побочные эффекты:

В этом примере выполняется вычисление MULTIPLY(x + 5) и ожидаемый результат — 50. Но в процессе подстановки произойдёт следующее преобразование:

MULTIPLY(x + 5) -> (x + 5 * 5)

Как несложно подсчитать, данное выражение выдаст не 50, а 30.

А вот как выполнить данную задачу правильно:

Инкремент и декремент

Допустим, есть такой код:

Здесь можно ожидать, что x будет увеличен на единицу и будет равен 6, а результат — 5. Но вот что получится в реальной жизни:

Виновата всё та же макроподстановка: ABS(x++) -> ((x++) < 0 ? - (x++): (x++))

Как видно, x увеличивается на единицу в первый раз при проверке и во второй раз при определении результата, что и приводит к соответствующим итогам.

Передача вызовов функций

Использованием функции в коде никого не удивишь. Равно как и передачей результата одной функции в виде аргумента для другой. Часто это делается так:

И в этой вставке кода всё в порядке. Но, когда это же производится с помощью макроса, можно столкнуться с серьёзными проблемами производительности. Допустим, есть вот этот код:

Здесь определена рекурсивная функция sum_chars. Она вызывается один раз для первой строки (str1) и другой раз — для второй (str2). Но, если передать вызовы функций, как аргументы для макроса, будет выполнено три рекурсивных вызова вместо двух. Для больших структур данных это станет узким местом производительности. Особенно, если макрос используется внутри рекурсивной функции.

Многострочные макросы

Программисты не всегда используют фигурные скобки вокруг единичных команд в циклах и условных операторах. Но, если произвести макроподстановку внутри этого блока, и этот макрос будет содержать несколько строк, это приведёт к весьма интересным результатам:

Во вставке кода выше нет фигурных скобок в первом цикле и, так как макрос заменяет одну строку несколькими, только первое выражение в макросе выполняется в цикле. Следовательно, это приведёт к бесконечному циклу, так как i никогда не увеличится.

Прим. перев. Эту проблему также можно решить с помощью упомянутого выше трюка с do {} while (0).

Именно из-за таких особенностей многие стараются избегать использования макросов.

Хорошая практика

Чтобы свести к минимуму проблемы, вызванные использованием макросов, хорошей практикой будет использование единого подхода для определения макросов в вашем коде. Каким будет этот подход, не имеет значения. Есть проекты, в которых все макроопределения объявлены в верхнем регистре. В некоторых проектах в начале имени макроса используют букву «m». Выберите себе любой подход, но этот подход должен быть таким, чтобы и вы, и другой программист, который будет работать с вашим кодом, сразу понимал, что имеет дело с макросами.

Прим. перев. Другие полезные практики оформления кода можно посмотреть в нашей статье.

Вывод

В большинстве случаев программисты предпочитают использовать функции, поскольку макросы скрывают некоторые серьёзные побочные эффекты. Тем не менее, использование макросов иногда более целесообразно. В этом случае нужно соблюдать правила их именования и учитывать специфику их использования, рассмотренную в статье.

Поддержка функций языка

• Полностью переработаны процедуры обработки списков инициализации. Больше никаких навязчивых ложных предупреждений вроде «слишком много аргументов» или «нет совпадающего конструктора». Помимо всего прочего, устранены неисправности с переменными типа auto и отображением некорректных сообщений об ошибках:
• Усовершенствованы процедуры анализа кода и навигации. В частности, устранены проблемы, связанные с некорректной порядковой обработкой:
• Добавлена поддержка расширений MSVC, существенно снижающая вероятность отображения ложных сообщений об ошибках.
• Реализована поддержка библиотеки JUCE для разработки кросс-платформенных аудио-модулей.
• Добавлена поддержка объявления дружественного синтаксиса C++11.
• Реализована поддержка макроса __COUNTER__:
• Добавлена возможность генерации дефиниций (Ctrl+Shift+D в Linux/Windows, ⇧+⌘+D в macOS) для шаблонов функций.
• Реализована функция автоматического преобразования блоковif-else после инвертирования условия:
• Внедрен кросс-платформенный динамический анализатор кода Valgrind Memcheck:
• Добавлена поддержка фреймворка для тестирования Boost.Test:
• Реализована возможность настраивать наборы инструментов для разных проектов. Пример персональной настройки наборов в macOS: И Windows:

С другими изменениями можно также ознакомиться в традиционном кратком видео-обзоре:

Более подробный список нововведений доступен на официальной странице обновления.

• 2D- и 3D-векторы;
• кватернионы;
• матрицы;
• функции плавности.

Реализация объектов поддерживает как стандарт С99, так и более новые.

Тип float

Каждая структура и функция библиотеки использует тип float, поскольку в большинстве своём в разработке 2D- и 3D-игр при помощи OpenGL применяется именно этот тип данных.

Передача по значению или по указателю

Для функций, принимающих в качестве параметров структуры, предусмотрено две версии реализации. Первая — когда структура передаётся по значению, вторая — по указателю. Второй вид функций имеет префикс p перед именем типа (pvector2, pvector3, pquaternion и pmatrix), а результат записывается в передаваемый аргумент *result.

Векторы

Все векторы (2D, 3D и кватернионы) имеют вид структур типа struct vec. Отметим, что компонента z может быть использована и для 2D-векторов, поскольку она применяется в OpenGL для проверки глубины. Компонента w используется только для описания кватерниона.

Матрицы

Все матрицы в библиотеке имеют размер 4×4. В MATHC также реализованы функции для настройки матриц модели, мира и проекции. Обычно матрица мира используется для изменения множества вершин на стороне клиента или на графическом процессоре. Если вы хотите изменить вершины на стороне клиента, то используйте функции matrix_multiply_f4() или pmatrix_multiply_f4() для изменения массива с 4 float-элементами:

Если вы хотите изменить вершины на стороне GPU, то используйте функции matrix_to_array() или pmatrix_to_array() для перевода матрицы в массив с 16 float-элементами:

Функции плавности

Функции плавности полезны для анимации. Библиотечная реализация функций основана на их описании. Функции принимают значения от 0.0f до 1.0f и возвращают значения внутри этого же диапазона. Однако в некоторых из функций возвращаемое значение экстраполирует этот диапазон.

Лицензия MATHC

Исходный код проекта подчиняется лицензии ZLIB.

Как работает алгоритм

При использовании изображения или видеокадра выполняются следующие действия:

1. Входное изображение разбивается на прямоугольные ячейки одинакового размера. Размер сетки соответствует высоте и ширине одной ячейки (т.е. символу шрифта), полученным из кодовой книги на этапе обучения.
2. Для каждой ячейки из кодовой книги выбирается символ, который заменит в ней «сырые» пиксели. Этим занимается дерево решений, в которое подаются эти пиксели.
3. Большой набор изображений переводится в ASCII с учётом индекса структурного сходства и используется в качестве обучающего набора данных.

Руководство по началу работы

Встроить библиотеку в ваше приложение не составит труда. Для этого нужно лишь добавить ascii_art.c и его заголовочный файл в ваше дерево исходного кода и скачать шестнадцатеричную модель, а также выполнить следующие вызовы API:

1. Сначала вызовите AsciiArtInit, чтобы инициализировать структуру ascii_render, определенную в заголовочном файле ascii_art.h.
2. Подготовьте изображение, которое нужно обработать, переведя его в оттенки серого. Для этого можно использовать внешнюю библиотеку вроде cvtColor из OpenCV или встроенный интерфейс AsciiArtLoadImage.
3. Выделите буфер, достаточно большой для хранения всех выходных данных. Количество необходимых байтов можно получить через интерфейс AsciiArtTextBufSize. Этот шаг является необязательным, если вы хотите не выводить текст, а получить двоичное изображение из ASCII-символов.
4. Наконец, преобразуйте входное изображение в символы ASCII с помощью AsciiArtRender.

Ниже представлена простая программа на С, которая которая демонстрирует типичное использование этих интерфейсов.

Также доступна демо-версия программы.

Проект реализован с использованием API сырых сокетов и FUSE (filesystem in userspace, файловая система в пользовательском пространстве), поэтому для полноценной работы и запуска проекта необходимы права суперпользователя. Linux является единственной ОС, на которой возможно запустить программу. Поддерживаются обе версии протокола удалённых хостов, IPv4 и IPv6.

Работа с проектом

Для компиляции проекта необходимо запустить make в корневой папке. Чтобы начать использование, необходимо:

• Создать текстовый файл с именами хостов и их IP-адресами;
• Запустить программу в режиме root-пользователя при помощи команды: ./pingfs <название файла> <точка монтирования>. Программа начнёт проверку хостов на правильность их реакции посредством отправки нескольких пингов. На экран будет выведена некоторая информация и статистика, затем будет произведено монтирование файловой системы;
• pingfs останется запущенным и будет печатать статистику по пакетам и байтам каждую секунду.

Чтобы остановить работу программы:

• Нажмите Ctrl+C;
• В противном случае, можно воспользоваться командой fusermount -u.

Поддерживаемые операции

• Создание и удаление обычных файлов;
• Листинг файлов;
• Переименование файлов;
• Чтение, запись и усечение файлов;
• Настройка и получение прав на доступ к файлам.

Неподдерживаемые операции

• Создание и удаление каталогов;
• Создание жёстких и мягких ссылок на файлы;
• Временные отметки (в этой версии они всегда равны 0).

Автор проекта отмечает, что в настоящее время производительность обработки LAN-хостов слишком низкая. Передача данных между ними часто приводит к потере пакетов, поэтому используйте pingfs с осторожностью.

В качестве шутки над идеей проекта пользователи Reddit уже придумали ему девиз:

Где мои данные? Не могу сказать. Но они существуют? Надеюсь.

• пустые конструкции if/else/try/catch/finally;
• неиспользуемые локальные переменные и параметры;
• использование кода с высокой цикломатической и NPath сложностью;
• избыточное использование конструкций if и ненужных скобок;
• код с запашком — использование длинных методов и длинных списков параметров;
• плохие практики написания кода — переназначение параметров, неправильное использование логики.

Функциональность OCLint

Статический анализ кода призван обнаруживать критические дефекты кода, которые не видны компилятору, но способны обрушить программу в будущем. OCLint автоматизирует процесс проверки кода при помощи расширенных функций:

• Динамическая загрузка правил в систему, даже во время выполнения;
• Гибкие и расширяемые конфигурации программы гарантируют пользователю настройку поведения OCLint именно под нужды каждого;
• Возможность вызова инструмента из командной строки вносит непрерывную интеграцию и постоянную проверку кода в процессе разработки. Это поможет исправлять все баги ещё на этапе разработки;
• Снижена вероятность ложных срабатываний инструмента для избежания ситуаций, когда полезный код может быть помечен как избыточный;
• Эффективность и точность инструмента основана на использовании абстрактного синтаксического дерева исходного кода.

Установка инструмента

OCLint является автономным инструментом, работающим на платформах Linux и macOS. Получить самую свежую версию 0.13 продукта вы можете, загрузив и самостоятельно скомпилировав исходный код, либо уже скомпилированные двоичные файлы программы.

Процесс установки подробно описан на специальной странице инструмента. Также доступно руководство пользователя с подробным описанием использования команд инструмента. Продукт распространяется под лицензией Modified BSD.

Цель курса — формирование практических навыков и умений, необходимых специалистам по разработке программного обеспечения UNIX-подобных операционных систем для участия в проектах промышленной разработки среднего уровня сложности на языках C/C++, в том числе для замещения стажерских должностей разработчиков серверной части высоконагруженных приложений.

Смотрите еще больше обучающих материалов по языкам C и C++.

В курсе будут рассмотрены следующие темы:

• отличия микроконтроллеров от традиционных компьютеров;
• обзор популярных семейств микроконтроллеров (ARM, AVR, MSP430 и др.) , их возможностей, а также проектов на их основе;
• настройка среды разработчика и написание программ на Си и Ассемблер;
• обзор периферийных интерфейсов и протоколов;
• ввод/вывод общего назначения и подключение различных внешних устройств;
• работа с прерываниями и таймерами;
• сведения о начальной загрузке и инициализации контроллера.

Совет Не стоит сдавать или использовать (даже в изменённом виде) приведённый ниже код в качестве домашнего проекта в школе или вузе. Многие преподаватели знают об оригинальной статье и уличат вас в обмане.

Жизненный цикл командной оболочки

Оболочка выполняет три основные операции за время своего существования:

1. Инициализация: на этом этапе она читает и исполняет свои файлы конфигурации. Они изменяют её поведение.
2. Интерпретация: далее оболочка считывает команды из stdin и исполняет их.
3. Завершение: после исполнения основных команд она исполняет команды выключения, освобождает память и завершает работу.

Именно эти три операции мы будем использовать как основу для нашей командной оболочки. Мы не будем добавлять дополнительные файлы конфигурации и команду выключения. Будем лишь вызывать функцию цикла и завершать работу. Стоит отметить, что, с точки зрения архитектуры, жизненный цикл сложнее, чем просто цикл.

В примере выше можно увидеть функцию lsh_loop(), которая будет циклически интерпретировать команды. Реализацию рассмотрим чуть ниже.

Базовый цикл командной оболочки

В первую очередь нам нужно подумать о том, как программа должна запускаться. И здесь важно понимать, что делает оболочка во время цикла. Простой способ обработки команд состоит из трех шагов:

1. Чтение: считывание команды со стандартных потоков.
2. Парсинг: распознавание программы и аргументов во входной строке.
3. Исполнение: запуск распознанной команды.

Эта идея реализована в функции lsh_loop():

Пройдемся по коду. Первые несколько строк — это просто объявления. Цикл с постусловием более удобен для проверки состояния переменной, поскольку выполняется перед проверкой ее значения. Внутри цикла выводится приглашение ввода, вызываются функции для чтения входной строки и разбиения строки на аргументы, а затем исполняются аргументы. Далее освобождается память, выделенная под строку и аргументы. Стоит обратить внимание, что в коде используется переменная состояния, возвращаемая в lsh_execute() и определяющая, когда нужно выйти из функции.

Чтение строки

Чтение строки из стандартного потока ввода — это вроде бы просто, но в C это может вызвать много хлопот. Беда в том, что никто не знает заранее, сколько текста пользователь введет в командную оболочку. Нельзя просто выделить блок и надеяться, что пользователи не выйдут за него. Вместо этого нужно перераспределять выделенный блок памяти, если пользователи выйдут за его пределы. Это стандартное решение в C, и именно оно будет использоваться для реализации lsh_read_line().

В первой части много объявлений. Стоит отметить, что в коде используется старый стиль C, а именно объявление переменных до основной части кода. Основная часть функции находится внутри, на первый взгляд, бесконечного цикла while(1). В цикле символ считывается и сохраняется как int, а не char (EOF — это целое число, а не символ, поэтому для проверки используйте int). Если это символ перевода строки или EOF, мы завершаем текущую строку и возвращаем ее. В обратном случае символ добавляется в существующую строку.

Затем мы проверяем, выходит ли следующий символ за пределы буфера. Если это так, то перераспределяем буфер (при этом проверяем его на наличие ошибок распределения) и продолжаем исполнение.

Те, кто знаком с новыми версиями стандартной библиотеки C, могут заметить, что в stdio.h есть функция getline(), которая выполняет большую часть работы, реализованной в коде выше. Эта функция была расширением GNU для библиотеки C до 2008 года, а затем была добавлена в спецификацию, поэтому большинство современных Unix-систем уже идут с ней в комплекте.  С getline функция становится тривиальной:

Парсинг строки

Теперь нам нужно распарсить входную строку в список аргументов. Мы сделаем небольшое упрощение и запретим пользователю использовать кавычки и обратную косую черту в аргументах командной строки. Вместо этого для разделения аргументов мы просто будем использовать пробелы. Таким образом команда  echo "вот сообщение" будет вызывать команду echo не с одним аргументом "вот сообщение", а с двумя:"вот" и "сообщение".

Теперь всё, что нам нужно сделать — разбить строку на части, используя пробелы в качестве разделителей. Это значит, что мы можем использовать классическую библиотечную функцию strtok.

Реализация этой функции подозрительно похожа на lsh_read_line(), и это неспроста! Здесь используется та же стратегия, только вместо нуль-терминированного массива символов мы используем нуль-терминированный массив указателей.

Мы начинаем разбиение, вызывая strtok. Она возвращает указатель на первый кусок строки (токен). Вообще strtok() возвращает указатели на места в строке и помещает нуль-терминаторы в конце каждого токена. Эти указатели мы храним в отдельном массиве.

При необходимости мы перераспределим массив указателей. Повторяем процесс до тех пор, пока strtok не перестанет возвращать токены, и завершаем массив токенов нуль-терминатором.

Теперь у нас есть массив токенов, готовых к исполнению.

Как командные оболочки запускают процессы

Теперь мы добрались до самой сути того, что делает оболочка. Запуск процессов — это основная функция командных оболочек. Поэтому если вы создаёте оболочку, то должны точно знать, что происходит с процессами и как они запускаются. Именно поэтому сейчас мы поговорим о процессах в Unix.

В Unix есть только два способа запуска процессов. Первый (который не будем брать в счет) — это Init. Видите ли, когда загружается Unix-система, загружается её ядро. После загрузки и инициализации ядро запускает только один процесс, который называется Init. Этот процесс выполняется в течение всего времени работы компьютера, и  управляет загрузкой остальных процессов, которые необходимы для его работы.

Поскольку все остальные процессы не Init, остаётся только один практический способ запуска процессов: системный вызов fork(). Когда эта функция вызывается, операционная система делает дубликат процесса и запускает их параллельно. Первоначальный процесс называется «родительским», а новый — «дочерним». Дочернему процессу fork() возвращает 0, а родителю — идентификатор процесса (PID) его дочернего элемента. Таким образом, любой новый процесс можно создать только из копии уже существующего.

Это может показаться проблемой. Обычно, когда вы хотите запустить новый процесс, вам не нужна копия уже работающей программы — вы хотите запустить другую программу. Для этого нужно использовать системный вызов exec(). Он заменяет текущую запущенную программу совершенно новой. Это значит, что при вызове exec операционная система останавливает процесс, загружает новую программу и запускает ее на том же месте. Вызов exec() не возвращает процесс, если нет ошибки.

Благодаря этим двум системным вызовам и возможен запуск большинства программ в Unix. Сперва существующий процесс раздваивается на родительский и дочерний, а затем дочерний процесс использует exec() для замены себя новой программой. Родительский процесс может продолжать делать другие вещи, а также следить за своими дочерними элементами, используя системный вызов wait().

Да уж, информации немало. Давайте посмотрим на код запуска программы:

Эта функция принимает список аргументов, которые мы создали ранее. Затем она разворачивает процесс и сохраняет возвращаемое значение. Как только fork() возвращает значение, мы получаем два параллельных процесса. Дочернему процессу соответствует первое условие if (где pid == 0).

В дочернем процессе мы хотим запустить команду, заданную пользователем. Поэтому мы используем один из вариантов системного вызова exec, execvp. Разные варианты exec делают разные вещи. Одни принимают переменное количество строковых аргументов, другие берут список строк, а третьи позволяют указать окружение, в котором выполняется процесс. Этот конкретный вариант принимает имя программы и массив (также называемый вектором, отсюда 'v') строковых аргументов (первым должно быть имя программы). 'p' означает, что вместо предоставления полного пути к файлу программы для запуска мы укажем только её имя, а также скажем операционной системе искать её самостоятельно.

Если команда exec возвращает -1 (или любое другое значение), значит, произошла ошибка. Таким образом, мы используем perror для вывода сообщения об ошибке вместе с именем программы, чтобы было понятно, где произошла ошибка. Затем мы завершаем процесс, но так, чтобы программная оболочка продолжала работать.

Второе условие (pid < 0) проверяет, произошла ли в процессе выполнения fork() ошибка. Если ошибка есть, мы выводим сообщение об этом на экран, но программа продолжает работать.

Третье условие означает, что вызов fork() выполнен успешно. Там находится родительский процесс. Мы знаем, что потомок собирается исполнить процесс, поэтому родитель должен дождаться завершения команды. Мы используем waitpid() для ожидания изменения состояния процесса. К сожалению, у waitpid() есть много опций (например, exec()). Процессы могут изменять свое состояние множеством способов, и не все состояния означают, что процесс завершился. Процесс может либо завершиться обычным путём (успешно либо с кодом ошибки), либо быть остановлен сигналом. Таким образом, мы используем макросы, предоставляемые waitpid(), чтобы убедиться, что процесс завершен. Затем функция возвращает 1 как сигнал вызывающей функции, что она снова может вывести приглашение ввода.

Встроенные функции оболочки

Возможно, вы заметили, что функция lsh_loop() вызывает lsh_execute(), но выше мы назвали нашу функцию lsh_launch(). Это было намеренно! Дело в том, что большинство команд, которые исполняет оболочка, являются программами — но не все. Некоторые из команд встроены прямо в оболочку.

Причина довольно проста. Если вы хотите сменить каталог, вам нужно использовать функцию chdir(). Дело в том, что текущий каталог является свойством процесса. Итак, допустим, вы написали программу cd, которая изменяет каталог. Она просто меняет свой текущий каталог и завершается, но текущий каталог родительского процесса не изменится. Вместо этого процесс оболочки должен исполнить chdir(), чтобы обновить свой текущий каталог. Затем, когда он запускает дочерние процессы, они также наследуют этот каталог.

Аналогично программа с именем exit не сможет выйти из командной оболочки, которая ее вызвала. Эта команда также должна быть встроена в оболочку. Кроме того, большинство оболочек настраиваются с помощью сценариев конфигурации, таких как ~/.bashrc. Эти сценарии используют команды, которые изменяют работу оболочки. Сами же команды могут изменить работу оболочки, если только они были реализованы внутри самой оболочки.

Соответственно, имеет смысл добавить некоторые команды в оболочку. В эту оболочку мы добавим cd, exit и help. А вот и реализация этих функций:

Код состоит из трёх частей. Первая часть содержит предваряющее объявление функций. Предваряющее объявление — это когда вы объявляете (но не определяете) что-то, чтобы можно было использовать это имя до его определения.lsh_help() — причина, по которой мы делаем это. Она использует массив встроенных функций, а сами массивы содержат lsh_help(). Самый простой способ разбить этот цикл зависимостей — это предваряющее объявление.

Следующая часть представляет собой массив имён встроенных команд, за которыми следует массив соответствующих функций. Это значит, что в будущем встроенные команды могут быть добавлены путем изменения этих массивов, а не большого оператора switch где-то в коде. Если вы смущены объявлением builtin_func, все в порядке. Это массив указателей на функции (которые принимают массив строк и возвращают int). Любое объявление, включающее указатели на функции в C, может стать действительно сложным.

Наконец, идет реализация каждой функции. Функция lsh_cd() сначала проверяет наличие своего второго аргумента и выводит сообщение об ошибке, если его нет. Затем она вызывает chdir(), проверяет наличие ошибок и завершает работу. Функция справки выводит информативное сообщение и имена всех встроенных функций. А функция выхода возвращает 0, как сигнал для окончания цикла команд.

Объединение встроенных функций и процессов

Последний недостающий фрагмент головоломки заключается в реализации функции lsh_execute(), которая либо запускает либо встроенный, либо другой процесс.

Код проверяет, является ли команда встроенной. Если это так, то запускает её, а в противном случае вызывает lsh_launch(), чтобы запустить процесс.

Собираем все вместе

Вот и весь код, который входит в командную оболочку. Если вы внимательно читали статью, то должны были понять, как работает оболочка. Чтобы испробовать оболочку (на Linux), вам нужно скопировать эти сегменты кода в файл main.c и скомпилировать его. Обязательно включите только одну реализацию lsh_read_line(). Вам нужно будет включить следующие заголовочные файлы:

• #include <sys/wait.h>waitpid() и связанные макросы
• #include <unistd.h>chdir() fork() exec() pid_t
• #include <stdlib.h>malloc() realloc() free() exit() execvp() EXIT_SUCCESS, EXIT_FAILURE
• #include <stdio.h>fprintf() printf() stderr getchar() perror()
• #include <string.h>strcmp() strtok()

Чтобы скомпилировать файл, введите в терминале gcc -o main main.c, а затем ./main, чтобы запустить.

Кроме того, все исходники доступны на GitHub.

Подводя итоги

Очевидно, что эта оболочка не является многофункциональной. Некоторые из ее упущений:

• аргументы разделяются только пробелами, нет поддержки кавычек или обратного слеша;
• нет перенаправления и конвейеров;
• мало встроенных функций;
• нет подстановки имён файлов.

Чтобы разобраться в системных вызовах, рекомендуем обратиться к мануалу: man 3p. Если вы не знаете, какой интерфейс вам предлагают стандартная библиотека C и Unix, советуем посмотреть спецификацию POSIX, в частности раздел 13.

Что изменилось?

Популярность Python продолжила расти, и он переместился на два места вперед. Однако рейтинги четвёрки лидеров: Python, C, Java и C++ — не сильно различаются. В настоящее время, по меркам востребованных компаний, C на голову опережает Python.

C# вернулся в первую пятерку, забрав место, которое принадлежало R в прошлом году. Ruby, к сожалению, упал до 12-й позиции, но при этом он дал шанс Swift присоединиться к Go в первой десятке. Это впечатляет, ведь Swift дебютировал в рейтинге всего два года назад. Полная противоположность Swift — это Objective-C, он опустился аж до 26 места.

Уже второй год подряд в рейтинг не входят новые языки. Программисты заняты осваиванием уже созданных инструментов для работы с облачными и мобильными приложениями.

Говоря о ветеранах среди языков программирования, стоит отметить присутствие в середине рейтинга такого языка, как Fortran (на 28 месте). На 35 месте расположился Lisp, а на 40 — Cobol. Приятно осознавать, что языки, которые использовались десятилетиями, по-прежнему вызывают интерес.

Для создания своего рейтинга специалисты IEEE используют 12 различных метрик из 10 источников. Основные показатели — это поисковая выдача по запросу с названием языка программирования и требования работодателей. Также учитываются данные Google Trends и упоминания в социальных сетях.