C++ *

Не бойтесь std::set, его легко приручить.

Эта небольшая статья для тех, кто имеет некоторое представление об ассоциативных контейнерах стандартной библиотеки C++ (std::map, std::set и т.д.), но пока не использовал «множество» (std::set) в повседневной жизни. Этот контейнер позволяет наиболее изящно организовать коллекцию «самоидентифицируемых» объектов, не трубующих внешнего «ключа» для поиска. Но работа с std::set имеет свои особенности, о них и пойдет речь. Каких-то принциапиальных открытий статья не содержит, я просто решил собрать в одном месте некий минимально необходимый набор приемов для работы со множествами и, таким образом, несколько сэкономить время читателя, впервые решившего использовать «множества» в реальных проектах. Сразу оговорюсь, я сознательно снизил планку стандарта C++ до минимально необходимой, чтобы код, приведенный здесь, мог использоваться максимально широко (так что просьба не удивляться громоздким «устаревшим» конструкциям вроде enable_if).

... Отлично, std::set — это то, что нужно! Зачем мне std::map, если ключ уже находится внутри моего объекта! Такова была моя первая восторженная реакция после знакомства с «множеством» (std::set) стандартной библиотеки шаблонов C++. Это было давно... очень давно.

Это экспериментальный формат, главная цель объяснить как отобразить текст, но а дальше идёт полный перевод* всех интерфейсов и функций DirectWrite с примерами.

GitHub

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

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

В эпоху ИИ-хайпа многие обещают, что теперь кодить не нужно — достаточно «поговорить» с моделью. Автор решил проверить это на практике: за три вечера, используя только бесплатные версии Claude и Qwen, он создал прототип приложения для мониторинга игровых событий в реальном времени через чтение памяти процесса Royal Quest.

Путь оказался тернистым: от неактуальных логов и зашифрованного трафика — к CheatEngine, Wine на macOS, PyInstaller и проблемам с кодировкой. Чат-модели помогли быстро сгенерировать ядро приложения, реализовать экспорт в JSON/TXT и даже простой дашборд, но каждая итерация сопровождалась багами, потерей контекста и переписыванием кода с нуля.

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

Результат — рабочий MVP, открытый на GitHub, и убедительный вывод: ИИ — мощный соавтор, но пока ещё не замена внимательному разработчику.

Еще одна библиотека строк для Python? Легко - если у вас есть ИИ-помощник.

Рассказываю, что хотел сделать (действительно, ленивые строки), что получилось, как использовал ИИ, с какими проблемами столкнулся, какие выводы для себя сделал.

Вы когда-нибудь копировали код кастомного контрола из статьи, чтобы избавиться от мерцания, а потом обнаруживали, что он ломает совместимость, требует специфичных обработчиков и не работает в условной компиляции?
Я — да. И, как оказалось, проблема не в Windows API или GDI, а в фундаментальной ошибке проектирования: попытке «улучшить» стандартный интерфейс VCL, изменив сигнатуру OnPaint.

В этой статье я объясню, почему передача Canvas и Rect в обработчик — плохая идея, как правильно расширять TWinControl, и почему лучший компонент — тот, который пользователь даже не замечает.

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

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

Как компилятор выбирает лучшую перегрузку, если подходящих вариантов несколько? Интуитивно мы ожидаем, что более «точная» функция должна иметь приоритет над более общей и часто это ожидание мы переносим в правила для компилятора при написании шаблонов и ограничений. Общая идея здесь следующая: перегрузки можно не просто перечислять, а выстраивать в иерархию по степени специфичности, тогда одни функции будут описывать широкий класс типов, другие его подмножество, и, когда тип аргумента известен, компилятор должен выбрать ту функцию, чьи требования наиболее точно соответствуют этому типу. Эта логика заложена прямо в стандарте C++ и называется partial ordering, то есть частичный порядок, потому что не все перегрузки обязательно сравнимы между собой.

Sharpe 2.1 в pandas-бектесте, через три месяца реальной торговли упал до 0.3

Pandas-бектесты систематически завышают доходность на 30-70%. Одна строчка с shift(-1) и вы уже используете завтрашние данные для сегодняшних решений. Плюс survivor bias, плюс нереалистичные fills.

В статье разбираю источники look-ahead bias, сравниваю vectorized и event-driven подходы на данных MOEX (SBER, GAZP, LKOH за 2020-2024), мои замеры latency для Tinkoff API, и рассуждения о том, когда Python уже не вывозит и пора думать про C++

Проблема: когда из-за «оптимизации» код замедляется

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

Разработана программа с целью обучения и быстрого создания программ для управления робототехническими комплексами или электропреобразовательными установками. Программа представляет собой приложение для персонального компьютера (ПК) с операционной системой (ОС) Windows 10 и выше, разрядностью 64-бит, (версия 32-бит проверялась на Windows 7), позволяющее визуально создавать конфигурацию периферийных устройств микроконтроллеров (МК) STM8S103/STM8S105, что позволяет ускорить процесс создания “прошивки” для МК и (или) уменьшить количество ошибок при разработке. Программа по созданной визуально конфигурации, путем выбора из заданных альтернатив, ввода числовых значений и контроля правильности ввода (предупреждает об ошибках), формирует файлы проекта для программирования МК на языках C (с библиотекой SPL или программирование на уровне регистров) и Assembler (язык выбирается в настройках программы). Позволяет сохранить созданную конфигурацию в файл для использования в дальнейшем. Имеется необходимая справочная информация по МК, SPL, C упрощающая создание кода. Созданные файлы проекта можно перед отправкой в IDE редактировать в сразу этой программе.

Скачать программу Конфигуратор микроконтроллеров STM8S103/105.

Думаю, многие согласятся, что реализация корутин в C++20 с первого взгляда выглядит страшновато, а документация скорее более запутывает, чем вносит ясность. Многие воспринимают работу приостанавливаемых функций как некую магию со своими странными co_abracadabra()'ми и прочими promise_type'ами.
В этой статье я хочу разоблачить якобы стоящую за корутинами магию, сдёрнуть покровы и показать, что спрятано под столом у фокусника.

В этой статье я расскажу о том, как добавить в С++/CMake проект возможность чтения YAML-конфигов с помощью библиотеки yaml-cpp.

Начнем с краткого обзора интерфейса yaml-cpp, а потом разработаем небольшой проект, состоящий из библиотеки с функционалом чтения конфига и приложения, использующего эту библиотеку для получения настроек из YAML-файла.

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

Сейчас нейронки — это не хайп, а мейнстрим. На сколько сильно бы мы не обожглись на них в прошлых годах, к концу 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. Подход будет полезен командам с большим количеством репозиториев, внутренней документацией и требованиями к безопасности.