C++ *

Кратко расскажу о себе и о том, зачем возникла необходимость в подобном. Я более десяти лет пишу приложения под Android, около 5 лет под IOS, и сейчас переношу свои наработки под десктопы. Приложения мои предназначены для сисадминов, это SSH клиент, сетевые сканеры и тд. В общем, самое сложное — не сам интерфейс, а то, что под капотом. Когда я лишь начинал, я думал, что остановлюсь на платформе Android и стал пилить все на Java. Но затем осознал свою ошибку и исправил ее. На данный момент все мои приложения состоят из двух частей: общего для всех систем ядра на С++ и платформозависимого интерфейса, написанного на Java/Swift/C++ в зависимости от системы.

Оговорюсь сразу, эта статья будет лишь своего рода вступлением. Я покажу, как работать с объектно‑ориентированным кодом на C++ в Java оболочке (в JNI нам доступен экспорт С функций). Инициализировать объект, делать из него вызовы, удалять, при этом имея аналогичный класс в оболочке, будто бы наш код был написан на Java. Задача эта не слишком сложная, но прежде чем опытные прогеры закрыли эту статью, я оговорюсь, что в следующей части мы уже будем работать с каллбэками — вызовами Java листенеров из нашего С++ кода, а вот это уже задача совсем нетривиальная, требующая понимания работы JNI и Dalvik. Но обо всем по порядку.

Итак, у нас есть некий CPP класс и Java оболочка. Через JNI мы можем вызывать только С‑функции, то есть не объектный код. Так как же нам работать с ООП? Главная проблема — не столько вызовы, сколько хранение адреса объекта нативного класса. Лично для себя я нашел решение — хранить его в Java классе, как long. То есть, у нас получается приблизительно такой код:

Stratum 1 NTP-сервер на Raspberry Pi в 2025 году: DCF77 + GPS/PPS, chrony, libgpiod v2, когда все туториалы по «точному времени на Raspberry Pi» сломаны на современных системах. Разбираю почему — и показываю как сделать правильно.

Если кратко, то цель: компилятор некоторого подмножества языка Си на C++, который работает в compile-time. Компиляция будет происходить в кастомный байт-код для дальнейшего выполнения в ВМ уже в рантайме.

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

Игра «Жизнь» — это простой клеточный автомат, поэтому она должна хорошо поддаваться GPU-ускорению. Правила просты: каждая ячейка в двухмерной сетке или жива, или мертва. На каждом шаге мы подсчитываем живых соседей ячейки (включая диагонали). Если ячейка жива, она остаётся живой, если живы два или три её соседа. В противном случае она умирает. Если клетка мертва, она оживает, если живы ровно три соседа. Из этих простых правил возникает потрясающий объём сложности, о котором написаны подробные статьи.

Для простоты я буду рассматривать только сети N×N и пропущу вычисления на краях. Всё будет работать на Nvidia A40, а бенчмарк производительности я буду проводить при N=2¹⁶. Пока мы будем хранить каждую ячейку в виде 1 байта, поэтому весь массив займёт 4 ГБ.

Весь код выложен в репозитории GitHub.

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

И проблема не в том, что старые тезисы изначально были бессмысленными. Проблема в том, что их продолжают подавать как вечные законы природы - без даты, без контекста и без поправок на то, что индустрия в корне изменилась.

Например, фразы про “серебряную пулю” и "небезопасный С++ ", которые звучат почти в каждом популярном тексте о разработке и безопасности, и оба часто переворачиваются так, что становятся откровенной неправдой.

Асинхронное логирование давно считается “очевидной оптимизацией”: вынесли запись в отдельный поток — и всё стало быстрее.

Но если копнуть глубже, оказывается, что это не совсем так.

В предыдущей статье я разбирал производительность популярных C++ логгеров и показывал реальные цифры:
👉 https://habr.com/ru/articles/1012874/

Там уже было видно, что хорошо оптимизированное синхронное логирование может быть очень быстрым.

В этой статье разберёмся, почему async logging не делает логирование быстрее само по себе, и что на самом деле происходит внутри:

Привет, Хабр! Меня зовут Анастасия Черникова, я занимаюсь разработкой компиляторных технологий и инструментов на базе LLVM в Синтакоре.

Неопределенное поведение (undefined behavior, UB) по-разному выглядит с точки зрения компилятора и разработчика. Для первого оно, как правило, открывает дополнительные возможности для оптимизации. Для программиста же UB может стать проблемой, особенно если оно остается незамеченным и не учитывается при разработке.

В этой статье рассмотрим подход к поиску UB с использованием статического анализа. В качестве примера я использую clang-tidy: сначала разберу, как устроены существующие чекеры и как работают AST matchers, а затем покажу, как расширять их и добавлять собственные проверки, если стандартных возможностей оказывается недостаточно.

ДИСКЛЕЙМЕР:

Автор не призывает к игре с сторонним ПО. Вся информация, приведенная в статье - приведена лишь в образовательных и ознакомительных целях. Информация была взята из открытых источников и ни к чему не призывает.

СОДЕРЖАНИЕ:

MCP выглядит как удобный способ структурировать LLM-приложение, но за это приходится платить. При этом попытки «ускорить систему» через C++, IPC или смену сериализации не всегда дают ожидаемый результат. В статье разбираю, где на самом деле возникает latency и почему архитектура оказывается важнее, чем выбор технологий.

Анимация: генерирует последовательность из 255 высокоточных кадров в формате BMP (frame_000.bmp ... frame_254.bmp) и автоматически компилирует их в видеоролик (файл Mandelbrot.mp4) с частотой 30 кадров в секунду, используя встроенный FFmpeg.

Скачать последнюю версию (Windows и Linux)
В windows это Mandelbrot_windows.exe и ffmpeg.exe
https://github.com/Divetoxx/Mandelbrot-Video/releases
Выше README содержит English и Русский!

FFmpeg - "швейцарский армейский нож" для обработки видео. В 2026 году он остается отраслевым стандартом, поддерживаемым сообществом разработчиков открытого программного обеспечения. От YouTube и Netflix до профессиональных киностудий - все на него полагаются. И да, он совершенно бесплатный.

Ошибки шаблонов в C++ — отдельный жанр: вы ожидаете простой контракт к типу, а получаете десятки строк из глубин STL. Проблема не в компиляторе, а в том, что сами требования к типам в классических шаблонах долгое время оставались неявными. Concepts это меняют: они позволяют формализовать ожидания к типу прямо в коде, сделать перегрузку осмысленной, а ошибки — читаемыми. В этой статье разберём, как работают concepts, зачем они действительно нужны и как использовать их не как «синтаксический сахар», а как инструмент проектирования.

Я решил учить C не по учебникам, а через практику — сделать свою простую консольную игру. Не ради “проекта мечты”, а чтобы на собственных ошибках разобраться, как всё работает на самом деле.

Наверняка многие и не задумываются: а как на самом деле происходит возврат структур и других типов значений из функций? Что происходит под капотом, какие приемы задействует компилятор? В данной статье я постараюсь дать ответы на эти вопросы и сделать это просто и понятно.

cout - плохой отладчик! Как за 30 секунд найти место падения программы? Какие 7 команд GDB нужно знать каждому C++ разработчику? В этой статье я делюсь личным опытом: как я боялся GDB, думал, что это «магия для гуру», а потом понял, что 70% задач решается простыми командами.

Спойлер: главный страх - это неизвестность. А когда знаешь backtrace, break, next, print и info locals, GDB становится лучшим другом. Статья рассчитана на начинающих C++ разработчиков, которые хотят перестать бояться терминала и начать отлаживать системно.

Что ж... Недавно я увлекся C++, поэтому давайте разберемся в какой-нибудь технологии и напишем по ней статью. Мой выбор пал на WebRTC и клиент на Qt.

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

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

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

Одной из самых сложных частей C++ до сих пор считаются правила поиска имён, и ошибки связанные с name lookup проявляются обычно уже в рантайме. Код компилится и даже работает какое-то время, но при свете луны ведёт себя не так как ожидает программист. За простыми идентификаторами скрывается многоуровневая система областей видимости, категорий имён и специальных правил, и очень многое в нашем текущем стандарте растёт прямиком из восьмидесятых, частенько без изменений. Давайте посмотрим как компилятор видит имена в C++, какие области видимости существуют и почему они ведут себя по-разному.

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

Благими намерениями вымощена дорога в ад. Или как погоня за оптимизацией и производительностью может нарушить фундаментальные математические принципы.

В C++ уже есть корутины. Есть диапазоны. Есть готовые библиотеки.

Но это не мешает взять гаечный ключ и начать собирать генератор вручную.

В предыдущей статье макросы внезапно начинают изображать из себя язык: DO, LET, IS управляют препроцессорным ритуалом и создают DSL. Это синтаксис. Это оболочка. Это фронтенд.

(чтение предыдущей статьи необязательно для понимания этой)

Но ведь есть не только синтаксис, можно создать и конкретную семантику — генераторы.

В этой статье я строю велосипедный генератор. Самый честный.

В статье проектируется с нуля мобильное устройство для измерение емкости на микроконтроллере ATmega8.