C++ *

По данным отраслевых опросов, в 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++ и использует Conan, знают: сам по себе пакетный менеджер — это только полдела. Настоящее веселье начинается, когда нужно раскатать одинаковые настрйки на всю команду и десяток CI-нод. Репозитории, профили, хуки, кастомные настройки всё это хозяйство нужно как-то синхронизировать.

Раньше у нас был conan config install, который тянул конфиги из git-репозитория или zip-архива. Решение рабочее, но с душком: попробуйте воспроизвести сборку двухлетней давности, если за это время мастер-ветка с конфигами улетела далеко вперед.

В Conan версии 2.x (и последних минорных обновлениях) завезли киллер-фичу: conan config install-pkg. Теперь конфигурация — это полноценный пакет. Давайте разберемся, почему это меняет правила игры.

Долг оптимизацией красен: как мы повышали производительность таблиц

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

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

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

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

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

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

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

«Мы знаем, что вы вчера в 23:47 переписывались с Алексеем 14 минут. О содержании разговора нам неизвестно.» — Так выглядит мир, где сообщения зашифрованы, а метаданные — нет.

Привет, Хабр! Я занимаюсь разработкой open-source мессенджера (проект Xipher, C++/Android), и один из компонентов, который пришлось проектировать с нуля — защита метаданных. Не содержимого сообщений (E2EE сейчас есть у всех), а информации о самом факте общения: кто с кем, когда, сколько раз.

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

Исходники проекта открыты — ссылка на GitHub в конце статьи, если захотите покопаться или раскритиковать.

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

В этой части разберём как из кубиков с буквами 'О', 'П', 'Ж' и 'А' while true do end

Инструкция по сборке нового XBox 360 статического рекомпилятора RexGlue https://github.com/rexglue/rexglue-sdk

Иногда книга начинается с одной статьи, опубликованной в нужный момент и в нужном Хабре и в моём случае всё действительно началось с публикации про аллокаторы, которая несмотря на обилие технического материала, кода и схем набрала больше всего плюсов среди моих статей на околоплюсовую и игродев разработку. А дальше и сам цикл Game++ постепенно вырос из отдельных технических размышлений о C++, архитектуре движков и производительности в связный нарратив. За спиной Game++ стоит еще больше узкотехнических материалов в блоге и вики моей компании и я бы рад ими поделиться, да и делюсь периодически, но сами понимаете выкладывать можно не всё и даже из то, что выложено на Хабре, частенько было подрезано, ибо NDA и секретные технологии-бла-бла-бла. Та статья стала точкой, когда я увидел, что разрозненные тексты на самом деле образуют скелет будущей книги, нужно лишь перестать относиться к ним как к «постам» и начать воспринимать как главы. Идея написать книгу не пришла просто так, и несколько не связанных между собой людей и компаний связались и предложили переписать цикл статей в виде книги.

Мне 18 лет, и последние несколько месяцев я разрабатываю Xipher — мессенджер, который пишу с нуля на C++ (бэкенд) и Kotlin (Android). В какой-то момент я захотел добавить фичу, которой нет ни в одном популярном мессенджере: режим, в котором переписку невозможно подделать — ни участникам, ни мне как владельцу сервера, — и это можно проверить независимо, без доступа к серверу.

Так появился Xipher Provable Chat. В этой статье разберу, как именно это реализовано, какие решения я принял и с какими проблемами столкнулся.

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

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

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

Это вторая статья из цикла От MNIST к Transformer, цель которого пошагово пройти путь от простого CUDA ядра до создания архитектуры Transformer - фундамента современных LLM моделей. Мы не будем использовать готовые высокоуровневые библиотеки. Мы будем разбирать, как все устроено под капотом, и пересобирать их ключевые механизмы своими руками на самом низком уровне. Только так можно по настоящему понять как работают LLM и что за этим стоит. В этой статье разберем основы работы с памятью и две простые математические операции с точки зрения математики, но не такие простые с точки зрения CUDA ядер.

Приготовьтесь, будет много кода на C++ и CUDA, работы с памятью и погружения в архитектуру GPU. И конечно же математика что за этим стоит. Поехали!