C++ *

Код некоторых модулей Erlang/OTP старше, чем большинство современных junior-разработчиков. Эти файлы — настоящие цифровые патриархи, десятилетиями обеспечивающие работу банковских транзакций, телефонных сетей и систем обмена сообщениями. Мы решили заглянуть под "капот" этого языка-долгожителя, чтобы проверить, что именно скрывается в строках, на которые сегодня полагаются миллионы пользователей. А вот что мы нашли, узнаем в этой статье.

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

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

Многопоточное программирование в C++ традиционно ассоциируется с мьютексами, condition variables и потенциальными проблемами вроде deadlocks и race conditions. Однако современные стандарты C++ (начиная с C++11 и далее) предоставляют инструменты для написания высокопроизводительного многопоточного кода без классических блокировок. В этой статье рассмотрим продвинутые техники: lock-free программирование, атомарные операции и различные модели упорядочивания памяти.

Статья посвящена очереди сообщений окна в Windows. Рассматриваются все действия с нею. Статья предназначена в основном для новичков в DirectX & Direct2D.

Данная статья является альтернативой hello-world в DirectX от Microsoft в связи с излишней перегрузкой терминами и не нужной информацией. Объяснение для новичков, просто и понятно.

Основной целью этой работы было попытаться реализовать реалистичную сцену горного ландшафта с воздушным шаром, используя "чистый" C++ и QT только для вывода пикселей. Мне было интересно превратить код в картинку, не имея других инструментов.

Тем кто собирает что-то под windows и задумался о версионировании сборочного окружения.

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

Версии окружения поднимаются, само окружение усложняется, требование команд к окружению растут и расходятся. Как тут всем угодить?

Исторически так сложилось, что в linux docker заехал как родной, а вот в windows вроде бы есть, но про него не слышно, на Хабре так уж точно. Поэтому если вы решили это попробовать, то эта статья для вас.

Многие разработчики привыкли везде ставить if-проверки, даже для условий, гарантированных кодом. Зачем проверять то, что не может нарушиться? Такие проверки создают шум в коде и мусор в релизе. Assert решает эту проблему: документирует допущения и исчезает из финальной сборки. В статье покажу все преимущества assert'ов и предостерегу от подводных камней их использования.

В общем-то и целом, мой предыдущий эмулятор ZX Spectrum, написанный на go, работал. Показывал нужное (или очень близко к нужному) и давал чувство приближенности к программистам. Однако у него были очень фундаментальные проблемы, связанные исключительно с языком разработки. Ну по крайней мере я сейчас так думаю.

Другим движущим фактором все-таки была бесплатность БЯМок от cloud.ru (не реклама, да и бесплатности больше нет). Ну где еще можно на халяву пожечь сотни миллионов токенов и получить хоть что-то работающее?

В общем, я принял волевое решение переписать все на С++. Под катом дневник "переписчика", в котором я последовательно описываю все боли и страдания начинающего писателя эмуляторов. Желающим сразу посмотреть на конечный результат можно сходить на https://github.com/kiltum/zxcpp

Библиотеки на С слишком сложны. И в этой статье я хочу подробно описать что конкретно под этим имеется в виду и почему оно происходит

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

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

Для незнакомых с ситуацией вкратце - любая библиотека на С это в конечном счёте всего лишь набор .c файлов и набор .h файлов, а также опции компиляции которые записываются в современности в CMakeLists.txt. Для адекватных библиотек CMakeLists.txt обычно состоит из набора опций в самом верху (и только они нужны пользователю) и дальше описания таргетов (библиотеки, исполняемые файлы), зачастую это укладывается в сотню строк

Но по какой-то причине в реальности всё совсем не так и тут нужно смотреть на примеры

Типичным примером можно считать репозиторий OpenSSL. Взгляните на (ЧАСТЬ) того что видит перед собой человек, который хочет использовать OpenSSL:

Конец осени, первый снег и идеальный момент, чтобы заглянуть под капот системного софта. 22 ноября в Москве соберем системных инженеров, исследователей и разработчиков, чтобы обсудить, как устроены компиляторы, ядро Linux и драйверы. Митап разделен на два потока: С++ и C/Linux kernel. Регистрируйтесь и подключайтесь — офлайн или онлайн.

Я, как и многие другие другие разработчики на C++, слышал о преимуществах нового std::format: удобство, безопасность и высокая производительность по сравнению с более старыми способами форматирования строк. 

Моя жизнь была прекрасна и полна надежд, пока я не увидел один бенчмарк, где format оказался медленнее всех. Как же так? Неужели «устаревший» std::stringstream или даже operator+ все еще лучше? Далее расскажу о своем небольшом исследовании производительности форматирования, доступного разработчикам на C++, и о необычных результатах, которые я получил.

Всем привет! Сегодня на обзоре Скелетная анимационная система, её организация и упорядочивание.

Скелетная анимация в 3D - это инструмент для лучшего погружения в повествование.

Часто ли вам приходилось задаваться вопросом: как сделать скелетную систему для 3D? Как организовать данные, как удобнее? Возможно, есть какие-то желания, которые при реализации хотелось бы учесть. Именно таким вопросом я задался, каким-то вечером. И так я начал изучать, что и как сделать. Но всё глубже погружаясь в какие-то туториалы, я обращал внимание на то, как организован код, и всё ускользало, как сквозь пальцы. Казалось бы, вот код, но он как бисер, рассыпан по многочисленным файликам какого-то обзорщика. Так же в какой-то момент, я уже точно знал, как я хочу, чтобы выглядел код, какой мне бы хотелось. Конечно, не совсем так. Узнал о том, какой я хочу код, после некоторых тестов... В общем, предлагаю взглянуть на то, как я смог реализовать анимационную систему в моём стиле. Добро пожаловать в эту статью, кому интересно рассмотреть какие-то нюансы с первых строк кода.

Привет!

В этой статье я объясню как сделать ИИ летающего боевого дрона на движке Unreal Engine с использованием алгоритма A*.

Тема безопасного и эргономичного взаимодействия между Rust и C/C++ была популярна на конференции RustConf 2025, состоявшейся в Сиэтле, штат Вашингтон. Чендлер Каррут выступил с презентацией, в которой представил различные способы взаимодействия между Rust и Carbon — экспериментальным языком, который можно условно обозначить как «(C++)++». Он резюмировал, что, пусть возможности стыковки Rust с другими языками со временем расширяются, в обозримом будущем не стоит ожидать, что будет полноценно решена проблема его взаимодействия с C++. Поэтому как раз появляется ниша для Carbon, который может предложить иной подход для постепенного совершенствования существующих проектов на C++. Вот слайды к его презентации — для тех, кто хотел бы изучить код его примеров более подробно.

Ваш код принимает данные извне? Поздравляем, вы вступили на минное поле! Любой непроверенный ввод от пользователя может привести к уязвимости, и найти все "растяжки" вручную в большом проекте почти невозможно. Но есть "сапёр" — статический анализатор. Инструмент нашего "сапёра" — taint-анализ (aka анализ помеченных данных). Он позволяет обнаружить "грязные" данные, дошедшие до опасных мест без проверки. Сегодня мы расскажем о том, как он работает.

Осторожно: статья написана максимально простым языком. Так что если вы гик, но не умеете программировать — вам всё равно будет интересно!

Недавно я наткнулся на DIY-игровую консоль за 1.500 рублей — Waveshare GamePi13. Когда гаджет приехал ко мне, я запустил примеры игр от производителя... и оторопел от 5 FPS в Pong — это ж как плохо нужно код писать!

Не желая мириться с этим, я открыл схему устройства, даташит на RP2040 и принялся писать свой собственный BIOS. Если вам интересно узнать, как работают DIY-консоли «изнутри», можно ли запускать внешние программы на микроконтроллерах из RAM, как реализованы различные подсистемы BIOS, а в конце даже написать «Змейку» - добро пожаловать под кат!

Здравствуйте, друзья, меня зовут Ерохин Кирилл, я программист‑любитель, и в этом сентябре я втихаря провёл соревнование по алгоритмическому программированию на C/C++ под платформу «Эльбрус» (e2k), собрав 31 участника со всей России, результатами которого я решил поделиться с вами. А Хабр мне в этом поможет, ему не впервой.

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

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

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

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

в github, vscode и windows абсолютно каждое обновление уже несколько лет связано только с "ИИ", при этом ни один реальный показатель этих программ не стал лучше. В каждый поисковой запрос встроен ИИ, а качество поиска в гугле стало хуже (считал ли кто-то, сколько электричества ушло на это?)

Компилятор go переписывают на go, JavaScript существует больше 20 лет, появился TypeScript, но он... Всё также компилируется в обычный JavaScript, даже более объёмный, чем написанный вручную. До сих пор все оптимизации передачи джаваскрипта по сети не пошли дальше удаления пробелов из исходного текста, хотя на поверхности лежит трансляция TypeScript в бинарный JS, который позже напрямую быстрее интерпретируется и тратит в разы меньше сетевого трафика

Недавно я зашёл в браузер хром и решил поискать небольшую фразу в довольно объёмном файле.