C++ *

Сейчас нейронки — это не хайп, а мейнстрим. На сколько сильно бы мы не обожглись на них в прошлых годах, к концу 2025го топовые модели типа Gemini, GPT, Opus показывают достойные результаты при условии правильного формирования контекста. Используя любую прослойку между облаком и пользователем, можно голосом в вольном стиле отдавать нейронке даже нетривиальные задачи, которые она автономно решит и пошлет сигнал к действию тому или иному девайсу. Без сервера, полагаясь на облака, тратя пару долларов в месяц на API.

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

Рассмотрим пример — ESP32 обвешена цифровым микрофоном, внешней SD картой памяти и RGB светодиодами . Человек говорит в повествовательном стиле, девайс реагирует исполнением его команды ( в предустановленных рамках) включая нужный свет.

Под капотом ESP32 записывает голос пользователя через I2S‑микрофон и сохраняет его во флеш‑память или на SD‑карту. Это принципиальный момент: аудио очень быстро съедает оперативную память, и попытка держать его в RAM с большой вероятностью обрекает на хождение по минному полю. Поэтому пишем голос на флешку, что хоть и даст небольшую задержку, но обеспечивает надежный workflow. Дальше сохранённый аудиофайл отправляется по HTTPS в LLM — чаще всего это Gemini или OpenAI. За подробностями имплементации можно заглянуть в гайд от Google.

Как это работает.

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

Добрый день!

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

У меня есть больше 5 лет опыта разработки приложений на qt, но это мой первый собственный проект. Буду рада вашим комментариям и советам. Также буду рада, если эти статьи кому-нибудь пригодятся для разработки своих проектов.

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

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

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

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

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

Рассмотрим «простой» пример цикла, выполняющего сложение двух массивов. Слово «простой» взято в кавычки не случайно. Даже тезисное обсуждение эффективных методов сложения массивов на GPU (NVIDIA или AMD) с коллегами занимает несколько часов. Полноценно раскрыть эту тему в одной статье невозможно.
Поэтому сосредоточимся лишь на части примера – операции инкремента «i++» в управляющей части цикла.

Для анализа обратимся к книгам, рекомендованным на профильных it-ресурсах: Хабр, Яндекс.Практикум, Proglib и др.

Чтобы уточнить информацию, рассмотрим официальные руководства следующих производителей вычислительных устройств: CISC (Intel, AMD), VLIW (МЦСТ, Texas Instruments), RISC (Apple, Qualcomm, MediaTek и др.) и GPU (NVIDIA, AMD).

История концептов в C++ – один из самых показательных примеров того, как язык развивается не линейно, а через десятилетия экспериментов, откатов и переосмыслений. Первые идеи, которые мы сегодня называем концептами, появились ещё в конце 1990-х, когда стало очевидно, что шаблоны C++ имеют колоссальную выразительность, но практически не дают средств для описания намерений программиста. Шаблон можно было инстанцировать почти с любым типом, но ошибка проявлялась либо в виде километров сообщений компилятора, либо в виде неожиданного поведения в рантайме. Уже тогда Страуструп сформулировал проблему как «отсутствие контрактов для шаблонов», когда программист знает, что от типа требуется оператор + или ==, но язык этого не выражает.

Ранние предложения концептов были чрезвычайно амбициозными и стремились описывать не только синтаксис, но и семантику. Например, концепт EqualityComparable должен был означать не просто наличие operator==, но и выполнение математических свойств эквивалентности: рефлексивности, симметричности и транзитивности. Аналогично, концепты для упорядоченных типов предполагали строгую слабую упорядоченность, а для итераторов корректное поведение при многократном проходе. Это отражало академический взгляд на обобщённое программирование, сильно вдохновленный функциональными языками и работами Степанова.

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

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

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

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

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

Причем, если для подсчета ссылок в рантайме, решения существуют, то контроль переполнения стека невозможно сделать не только во время анализа исходного текста программы, но это практически невозможно и во время выполнения приложения! Ведь ошибка переполнение стека (stack overflow) - это всегда фатально, так как не существует способа поймать и обработать эту ошибку изнутри выполняемой программы, чтобы потом продолжить её выполнение как ни в чем не бывало.

Существует ли хотя бы теоретическая возможность защититься от ошибок переполнения стека и сделать из нее обычную ошибку (исключение), которую можно поймать (обработать) в самом приложении, чтобы была возможность продолжить выполнение программы без боязни последующей ошибки сегментации (segmentation fault) или повреждения стека (stack smashing)?

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

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

C++ — язык с долгой памятью. В нём до сих пор живут идиомы и приёмы, которые когда-то спасали разработчиков, а сегодня нередко мешают писать безопасный, быстрый и поддерживаемый код. Мы продолжаем использовать макросы, CRTP или iostream «по привычке», не всегда задумываясь о цене — сложности поддержки, скрытых багах, просадках производительности и времени команды. Разобраться, что в современном C++ действительно стоит брать в прод, а что пора оставить в прошлом, — важная задача для инженера, который не хочет тащить legacy в 2026 год.

Привет, Хабр! Недавно мы запустили шоу «АйТир Лист». В каждом выпуске берём одну тему из мира разработки и раскладываем её по тир-листу — от FAIL до GOD. В первом выпуске разбирали open source для фронтенда, а во втором выпуске — обсудим непростую тему фич и идиом С++.

Приглашённые эксперты — Антон Полухин, эксперт-разработчик C++ платформы городских сервисов Яндекса, и Даниил Черепанов, архитектор редакторов МойОфис.

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

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

Таким образом, если вас интересуют общие проблемы параллельных процессов, то в этой и в последующих статьях на примере логических процессов мы их и рассмотрим. Терминологически мы будем придерживаться словаря по вычислительной технике под редакцией В.Иллингоута[1].  Но это может быть учебная литература, подобная [2], научная литература, как монография  [3], или научно-популярные книги типа [4, 5].

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

У меня сформировался свой вариант модели конечного автомата  (КА), который далее будет основным. Данная модель, во-первых, очень близка к классической форме. А это важно, т.к. позволяет использовать теорию почти без исключений. А, во-вторых,  она удобна для практики программирования, допуская эффективную ее реализацию.  Более детально все эти вопросы освещены в статье [6].

В настоящее время многоядерные процессоры с гетерогенными архитектурами, в которых сочетаются ядра с различной производительностью, становятся всё более и более распространенными. Если ещё пару лет назад такие архитектуры были в основном распространены в мобильном сегменте (см. ARM BIG.little), то с анонсом в 2022 году компанией Intel процессоров 12-го поколения линейки Intel Core, такие процессоры стали распространяться в сегменте десктопов и рабочих станций. Однако, до сих пор остается открытым вопрос — необходимо ли каким‑то специальным образом учитывать особенности данных архитектур для достижения максимальной многопоточной производительности?

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

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

Работу автомата можно представить как множество параллельных процессов. Как же программно смоделировать множество параллельно работающих процессов?

Рассмотрим две проблемы при изучении иностранного языка. Это освоение грамматики и увеличение словарного запаса. Они не единственные, но важные. Про способы погружения в грамматику, на языке оригинала, можно прочитать в моей статье: «Уроки французского и пересоздание данных для изучения иностранного языка с помощью обучающей программы «L'école»», в https://habr.com/ru/articles/972594/ .

Там идея простая. Мы берем хороший учебник на языке оригинала, разбиваем текст на короткие смысловые фразы, снабжаем их фонетическим слогоделением и буквальным контекстным переводом (БКП). Затем, озвучиваем данные, например, с помощью TTS, для, в данном случае, обучающей программы «L'école» и создаем двуязычные html-тексты с транскрипцией (фонетическим слогоделение) или, другими словами, небольшую книгу в формате html.

Идея изучения грамматики основана на двух принципах:

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

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

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

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

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

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

Привет, Хабр!

Пожалуй, одним из первых устройств, которые подключаются к умному дому (конечно, после модуля управления освещением), является домашняя метеостанция. Вот и мне на новом месте и в новом умном доме потребовалось реализовать данное устройство. Но есть одна проблема: находясь вдалеке от своей домашней лаборатории, я имею минимальный набор инструментов и лишен таких благ цивилизации, как лазерный мини-ЧПУ для изготовления плат и 3D-принтер. Поэтому для реализации проекта будем работать по старинке, в режиме жесткого DIY-хардкора (или «Очумелых ручек»). Впереди много картинок и термоклея, так что включайте ваши паяльники и поехали!

Генерируем лабиринт на гексагональной сетке Uber H3 и ищем путь с помощью двунаправленного A* — всё это на Qt 6 с визуализацией на реальной карте

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

Вычисление обратной матрицы, а именно, вычисление алгебраических дополнений и определителя матрицы займёт большое количество машинных ресурсов при квадратной матрицы высокого порядка. В статье описывается решение и приводятся результаты обращения квадратной матрицы методом решения системы AX = E, где A, X, E - квадратные матрицы порядка n, X - обратная A матрица, E - единичная матрица, и методом LU декомпозиции.

Привет, Хабр!

Так уж сложилось, что 99% устройств моего «умного дома» были спроектированы и собраны самостоятельно — что тут поделать, каждый развлекается как может. Об одном из таких устройств я писал ранее, а именно — о модуле управления освещением с радарным датчиком HLK-LD2402. И в соответствии с жизненным циклом отладки, а также процессом эксплуатации устройства назрела необходимость в программных улучшениях, о которых я постараюсь коротко рассказать в этой статье.