C++ *

Привет! Меня зовут Николай, я C++-разработчик в SimbirSoft. Это продолжение цикла статей о проектировании библиотек на примере решения геометрических задач. В первой части мы разобрали классическое наследование с виртуальными функциями и использование шаблонов, сравнили их сильные и слабые стороны и посмотрели, какие ограничения возникают при расширении системы.

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

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

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

Короткий дисклеймер Я очень хочу, чтобы эта статья была просто научной работой. Чтобы никогда и никому не понадобился мой экзоскелет. К сожалению, пока это не так. По статистике у каждого есть хотя бы один близкий, кому он необходим.

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

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

Каждый раз, когда вы соединяете ноды в Blueprint и нажимаете Play, Unreal Engine запускает маленький процессор. У него свои инструкции, свой стек, своя защита от бесконечных циклов. Он написан в ~4000 строках C++ и живёт в одном файле. Через него проходит каждый Event Tick, каждый Event BeginPlay, каждый вызов Blueprint-функции.

Этот процессор - Blueprint VM (Virtual Machine). И сегодня мы разберём его по винтикам.

Небольшая инструкция для всех, кто работает в Unreal Engine и пишет на C++ или иных языках + компилирует файлы для Андроид.

Hobbes - это функциональный язык программирования со статической типизацией, написан на С++ и включает JIT-компилятор на базе LLVM. Похож на Haskell, но совсем не такой же революционный и гораздо менее известен. Я немного расскажу, что это за язык и как он устроен внутри.

После того, как вы настроили rexglue (https://habr.com/ru/articles/1002640/), можно переходить к следующему этапу.

Скачиваем iruka-demo, демо-версию с дельфином https://github.com/rexglue/demo-iruka

Представьте на минуту, что C++ — это не набор странных ключевых слов и ошибок линковки, а всего лишь ещё один способ поговорить о мире вокруг нас: о людях, числах, цветах, событиях и котах. Мы привыкли думать о программировании как о чём‑то сугубо техническом, где важно запомнить синтаксис, расставить точки с запятой и “угадать”, чего сейчас хочет компилятор. 

Но если задать себе вопрос «а чем вообще оперирует программа?», внезапно выясняется, что за всеми этими int, struct и template прячутся довольно простые и понятные идеи: вещи, их свойства, группы похожих вещей и правила, по которым одни вещи превращаются в другие.

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

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

Это продолжение серии. Если вы не читали первую часть, рекомендую начать с неё: https://habr.com/ru/articles/1000766/

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

Коротко о теме статьи. Стандартная библиотека C++ инициализирует механизм обработки исключений на раннем этапе, выделяя память для «резервного пула», чтобы можно было использовать её под выброс исключений, если malloc вдруг провалится.

Добрый день, в контексте моего хобби по схемотехнике и программированию микроконтроллеров появилась идея реализовать устройство для дистанционного запуска предпускового котла Webasto, в моем случае это "Webasto Thermo Top Evo 5". Вероятно предложенный материал подойдет и для реализации устройств управления для схожих отопителей данной марки работающих по протоколу W-bus.

Пока индустрия движется в сторону усложнения компиляторов, я задался вопросом: можно ли создать инструмент, который дает безопасность Rust, гибкость C и при этом не весит сотни мегабайт?

Так появился Flame — системный язык с компилятором в 226 КБ, который реализует управление памятью через статический анализ AST и предлагает альтернативный взгляд на обработку ошибок через патчинг дерева токенов.

Все началось со статьи Как собрать клон Yamaha DX7 за 10$. Так как я достаточно давно занимаюсь музыкой, и люблю конструировать всякие электронные штучки, меня эта статья заинтересовала. Я тут же начал прикидывать по цене возможные варианты. RPI2040 конечно же очень дешево, но посмотрев пару обзоров на Picodexed на YouTube, меня не привлекла простенькая синтезаторная составляющая. Понятно, что это полная эмуляция движка Yamaha DX7, но слишком уж звук невзрачный и простой. После просмотра вариантов эмуляторов синтезаторов на RPI на YouTube меня больше заинтересовали проекты MiniDexed, MT32-pi и Mini-JV880. 

Введение

Данный проект, является логическим продолжением развития темы "Солнечный трекер на Arduino".

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

Распознавать маркеры можно по разным критериям: выбранному цвету, текстуре, форме и т.д.

Я выбрал второй вариант. Делаю фото объекта web-камерой, с выбранным однородным цветом, которую буду использовать на роботе.

Подготовка ПО

Для корректной работы программы вам нужно:

1. Установить Python https://www.python.org/

2. Установить модули numpy, opencv и pyserial используя инструмент pip https://pypi.org/project/numpy/

https://pypi.org/project/opencv-python/

https://pypi.org/project/pyserial/

3. Установить Arduino ide

https://learnlange.blogspot.com/p/blog-page_28.html

Сборка робота

Система представляет стационарную установку с двумя степенями свободы, которые позволяют вращаться в пространстве цилиндрической формы. На верхней части системы закреплена USB web-камера (её можно заменить на smart камеру или ip камеру).

Для быстрого создания прототипа использую образовательный набор КЛИК: базовый и ресурсный
Поворотные механизмы реализованы с использованием DC моторов с понижающей передачей.

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

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

Я делал это не потому, что меня кто-то заставлял или потому что так требовало начальство, а просто потому что сам процесс создания работающей системы из ничего, исправление хитрых багов, построение сложных систем из простых компонентов – всё это было по-настоящему весело, приносило какое-то детское удовольствие от созидания. Когда наконец откидываешься в кресле от монитора после многих часов работы, смотришь на то что построил своими руками, и видишь что всё работает как задумано, и думаешь: "Да, я, блин, чертов гений, это всё сделал только я, и никто мне не помогал". Ну разве что SO и немного гуглежки.

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

Нередко при оптимизации приложений, написанных на языках со статической компиляцией (C, C++, Rust), наступает момент, когда стандартные методы оптимизации, такие как улучшение алгоритмов, подбор структур данных, флаги компиляции вроде -O3, перестают давать дополнительный прирост производительности. В этот момент многие вспоминают про фундаментальное ограничение статических компиляторов. В отличие от JIT, они не знают, какой код будет горячим, а какой холодным. JIT-компиляторы (JVM, V8, .NET) получают эту информацию в runtime и адаптируют оптимизации под реальную нагрузку. Статические компиляторы генерируют машинный код заранее и лишены информации о поведении программы в runtime. Для решения этой проблемы используется подход Profile Guided Optimization (PGO). Он позволяет собрать данные о выполнении программы и передать их компилятору для принятия более оптимальных решений при генерации кода. По сути, PGO - это способ дать статическому компилятору некоторые преимущества JIT, сохраняя при этом все преимущества ahead-of-time компиляции: отсутствие пауз на перекомпиляцию и полный контроль над билдом.

По данным отраслевых опросов, в 2025 году 84% разработчиков использовали ИИ-инструменты для написания, отладки и автоматизации кода. А в 2026 году ожидается, что более 80% компаний будут применять генеративный ИИ в разработке своих продуктов. Но у LLM есть ограничения, которые не позволяют им быть одинаково эффективными для всех языков программирования — например, для С++.

Тему ограничений AI в пайплайне «плюсовой» разработки обсудили Андрей Золотых и Илья Казаков из YADRO, Константин Владимиров из Синтакор, Илья Шишков из Сбертех и Денис Фокин из LRI. К каким выводам пришли эксперты, читайте под катом. 

Каждый, кто имел дело с Unreal Engine после 2014, наверняка слышал про скриптовый язык Blueprint. Но что реально происходит под капотом, когда вы таскаете ноды? Как создать свою ноду (и надо ли это вам вообще?) В данной статье я бы хотел разобрать K2Node

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

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

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

Функцию rand из стандартной библиотеки языка Си для генерации псевдослучайных чисел, наверное, не ругал только ленивый. В довольно известном докладе Rand considered harmful рассказывалось о проблемах с переносимостью, ограниченным диапазоном, многопоточностью, качеством и т.п. Иногда в учебниках упоминают о том, что алгоритм в rand может быть не очень качественным, иметь проблемы с младшими битами, периодом, прохождением статистических тестов. Но крайне редко можно увидеть разбор конкретных критериев, выявляющих дефекты генераторов. В этой статье я постараюсь наглядно показать не просто отдельные недостатки rand, lrand48 и random из glibc, но их полную непригодность для каких-либо вычислений в принципе. Также вы увидите превосходство поточных шифров над minstd, линейным конгруэнтным генератором из 1980-х, не только в качестве, но и в производительности.