C++ *

Это продолжение серии. Если вы не читали первую часть, рекомендую начать с неё: 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-х, не только в качестве, но и в производительности.

Представьте огромную библиотеку, где все книги — от кулинарных рецептов до квантовой физики — свалены в одну гигантскую кучу на полу. Чтобы найти книгу «Война и мир», вам придется перерыть весь завал, и высока вероятность, что вы достанете «Войну миров» Герберта Уэллса или методичку «Как сдать мир на войне». Примерно так выглядит глобальное пространство имен в C++ без использования namespace.

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

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

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

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

Довольно типичный случай — у вас есть вполне себе нормальная структура, которая хранит информацию об одном объекте. Но самих объектов очень и очень много. Скажем, у вас 1000x1000 клеток террейна. А это уже целый миллион объектов! И вот ваша структура размером с несчастные 32 байта множится миллион раз и разрастается до объемов 30.5 Mб оперативной памяти.

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

Множество Мандельброта. 32-бит TrueColor. 60 FPS. 80-бит long double. OpenMP. Суперсэмплинг 2x2 (4 прохода). И цвета. Я хочу сказать. Это самая нужная вещь во Вселенной. Самая глубокое. И я сейчас за всю жизнь наконец стал писать код и сделал. Довольно сложное. И самое прекрасное. Скачайте и посмотрите! Это экзешник, в ГитХаб.

github: Download Latest Version Windows And Source code

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

Наиболее эффективная техника, реализующая подобное взаимодействие, известна как тройная буферизация (Triple Buffering). Именно о ней и о её небольших обобщениях пойдет речь в данной статье.

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

Меня зовут Дмитрий Шубин, я занимаюсь оптимизацией производительности в компании МойОфис — конкретно в Ядре редакторов (о нём ранее рассказывал мой коллега в статье «Как мы создаём редакторы документов. Ядро и его роль в кроссплатформенной разработке»).

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

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

Продолжаем серию «C++, копаем вглубь». Цель этой серии — рассказать максимально подробно о разных особенностях языка, возможно довольно специфичных. Это десятая статья из серии, список предыдущих статей приведен в разделе 9. Серия ориентирована на программистов, имеющих определенный опыт работы на C++. Данная статья посвящена приведениям типа.

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

Итак, попробуем рассказать о приведениях типа максимально подробно.