C++ *

Syn ack, Хабр!

С++ - это тяжелый выбор для кросс-платформенного open source проекта. Если вы выбрали С++, то вам нужно пройти следующие этапы:

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

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

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

Хабр и GitVerse обьявили конкурс, в котором попросили поделится своим опытом участия в open source проекте:

“Твои «грабли» — это уже отловленные баги для тех, кто идёт следом”

Я наткнулся на “грабли” в процессе разработки open source проекта на С++: Daggy - Data Aggregation Utility and C/C++ developer library for data streams catching. Чтобы вы могли отловить мои баги, стоит разобраться, откуда возникла идея еще одного open source проекта.

Показанным ниже кодом вы можете проверить на високосность год в интервале 0 ≤ y ≤ 102499 всего примерно тремя командами CPU:

bool is_leap_year_fast(uint32_t y) {

return ((y * 1073750999) & 3221352463) <= 126976;

}

Как это работает? Ответ на удивление сложен. В статье я объясню процесс; в основном он связан с забавным битовым жонглированием. В конце мы обсудим применение этого кода на практике.

Решил написать простенькую статейку по следам реализации небольшой программки на С++ под Виндоус, которая содержит в себе TCP сервер. Мы получаем от клиента http запрос. Соединение не защищенное.

На чем реализован клиент нам неизвестно: может на php (curl,socket,stream_contex_create,...), может на js (ajax), вообще может быть на чем угодно.

Надо задача реализовать http парсинг запроса и контента, выполнить задание (на каком-то подключенном к серверу оборудовании) и ответить клиенту о результате.

Примечание: автор реализует http сервер на устаревшем Qt4, используем QTcpServer. Но для http сервера это не принципиально.

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

Нас ждёт мозговыносящая смесь 64/32-битного ассемблера и старого-доброго C++. Мы сделаем собственную реализацию... Волокон (fibers) без вызова Win API и звонков в службу спасения.

Псевдокод, страсть и pull-request на грани добра и зла

Кто-то звал Smalltalk, кто-то бросал в нас Haskell, кто-то доставал из-под кровати подшивку статей «ECS лучше всего» — и всё это с праведной уверенностью.

В C++ инкапсуляция — один из ключевых принципов ООП, и приватные (private) члены класса защищены от прямого доступа извне. Однако иногда возникают ситуации, когда такой доступ необходим (например, при тестировании, сериализации или отладке). Обычно для этого используют friend-функции или геттеры/сеттеры, но есть и более экзотический способ — использование шаблонов и указателей на члены класса.

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

Расскажу, как устроена архитектура консоли Nintendo Gameboy, как можно эмулировать её основные компоненты, какие решения я принимал в процессе разработки и какие инструменты использовал.

После каждой новой статьи с заголовком «ООП — это обман» хочется напомнить: ООП — это не набор шаблонов из книжек, а инженерный подход. Если проект страдает от наследования и DI, возможно, проблема не в ООП. А в том, как вы его применяете.

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

Микроконтроллеры, светодиоды, и немного кода — вот и вся палитра для минималистичного цифрового искусства. В статье подробно рассказывается, как выстроить архитектуру крошечных, но выразительных световых анимаций с использованием C++, платформы STM32 и адресных светодиодов WS2812. Немного философии, немного инженерии — и свет оживает по команде вашего кода.

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

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

Мэтт Годболт, знаменитый разработчик Compiler Explorer — потрясающий человек, вам стоит найти в вебе и изучить весь созданный им контент. Именно этим и занимался, просматривая Correct by Construction: APIs That Are Easy to Use and Hard to Misuse. Я уже больше двадцати лет работаю с C/C++, поэтому эта тема была мне близка.

Когда я смотрел его доклад, ко мне постоянно приходила мысль: «Да! И именно поэтому в Rust это делается так». После просмотра видео я подумал, что этот доклад — отличный способ понять, как Rust помогает разработчикам не только в безопасности по памяти, и в своей статье я расскажу об этом.

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

Началось все с того, что при проектировании своего устройства на микроконтроллере ATtiny 85, которое должно было работать от встроенного li‑ion аккумулятора, я изначально не задавался целью измерения заряда АКБ, поскольку в этом не было необходимости. Однако, собрав все устройство на печатной плате, я подумал над тем, почему бы не добавить такую возможность.

Прочитав в Интернете, как это можно было реализовать, стало ясно, что сделать это вряд ли удастся, поскольку все порты PB[0:5] уже были заняты и, следовательно, не было возможности применения АЦП с аналогового пина (при чем порт PB0 я не мог настроить на вход опорного напряжения AREF - он должен был использоваться как управляющий выход).

Долгое изучение состояния регистров АЦП в datasheet на ATTiny 85 привело меня к следующей идее: в качестве опорного напряжения может быть выбрано само напряжение питания VCC (биты REFS [0:2] регистра ADMUX установлены в 0), а в качестве измеряемого ‑ напряжение VBG с внутреннего стабилизатора в 1.1В (биты MUX [3:0] регистра ADMUX установлены соответственно в 1100). То есть, для измерения напряжения питания не нужно ничего, кроме, собственно, самого питания VCC!

Даже в 2025 году, когда вокруг нейросети, автогенерация кода и IDE с предиктивным интеллектом, работа с редкими микроконтроллерами всё ещё может обернуться настоящим хардкором. Особенно, если речь идёт о «слепой» отладке без отладчика, когда в арсенале только прошивка, HEX-файл и пара байтов на выводе. В этой статье — личный опыт, много хардкора, дизассемблирование вручную и поиск глюка в 2 КБ бинаря.

Когда говорят «отладка», в 2025 году чаще всего имеют в виду жмяк на F5 в Visual Studio Code или лог с CI/CD. Но в embedded-мире, особенно если ты копаешься в системах с 8-битным контроллером 2006 года выпуска, это слово может означать кое-что пострашнее. Например — «прошивка вылетает на 4-й секунде, данных в UART нет, отладочного интерфейса нет, документации почти нет, а заказчик просит сделать "как раньше работало"». И вот тут начинается старый добрый reverse engineering.

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

После прочтения большинства этих статей и нескольких лет кодинга на C# я заявляю: «ООП - это один большой обман. Никто не понимает, что это такое. Люди просто говорят какие-то умные термины, их собеседники с умным видом кивают, хотя на деле трактуют эти же термины совершенно по-разному».

И вот почему.

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

Во время разработки одного из своих проектов я обнаружил, что мне нужен контейнер, способный менять свой размер по мере необходимости. Так как я большую часть времени разрабатываю на С++, а не на С, я очень хотел получить что-то похожее на std::vector<T> из С++. Я начал искать в интернете реализации, но они мне не подходили по разным причинам. Тогда я решил разработать свой вариант.

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

Я на тот момент как раз находился в поиске новой работы, поэтому предложение принял. Опустим стандартный звонок с этим рекрутером, с HR'ом компании и онлайн-тестовое и перейдём к более интересному - тестовому заданию. Сразу скажу, что тестовое не оплачивалось, и я взялся за него по нескольким причинам. Во-первых, оно мне и вправду понравилось, во-вторых, кодовую базу я планировал использовать в своём с корешами pet-проекте по финансам, в-третьих, не оставлял надежд пройти отбор до конца и получить желаемый offer. Спойлер - игра стоила свеч, поэтому прошу к прочтению.

В Steam завершился «Фестиваль передвижных ящиков», посвященный играм, где разными способами можно передвигать ящики. На английском фестиваль называется «Sokoban Fest» в честь первой игры, где появилась эта механика.

Игра-головоломка «Sokoban» (яп. 倉庫番, рус. кладовщик) вышла в Японии в 1982 году. А разработал ее годом ранее Хироюки Имабаяси. Она имела колоссальный успех. И механика привлекла тогда внимание многих геймдизайнеров, которые стали применять ее в новых играх и продолжают применять в современных играх разных жанров.

В своем проекте X-Drums 2.0 на Unreal Engine 5 мне захотелось добавить эту механику. И в этой статье я расскажу, что из этого получилось и какие еще игры повлияли на финальную реализацию.