Основной целью этой работы было попытаться реализовать реалистичную сцену горного ландшафта с воздушным шаром, используя "чистый" 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, который позже напрямую быстрее интерпретируется и тратит в разы меньше сетевого трафика
Недавно я зашёл в браузер хром и решил поискать небольшую фразу в довольно объёмном файле.
Привет, Хабр! Одна из задач при управлении роботами-манипуляторами – расчет обратной кинематики. Данный вид кинематики позволяет вычислить углы наклона суставов робота (joints) таким образом, чтобы захват (grip) робота пришел в заданные трехмерные координаты с правильным углом наклона. Для многих роботов уже есть алгоритмы и формулы вычисления обратной кинематики, мы (команда Zebrains) столкнулись с отсутствием готового решения для робота xArm 2.0.
В статье мы подробно опишем с какими сложностями столкнулись при управлении данным роботом, как получили формулы для расчета двух видов кинематики для данного робота и поделимся кодом на C++. В проекте использовался ROS2, ноды которого были написаны на C++.
Мат рождается в душе. Больше всего его рождается когда сталкиваешься с чем-то похожим на <подставь свой фреймворк>. Инструмент с прекрасными целями и задачами постепенно превращается во все больший и больший кусок г.. в котором приходиться копаться. Ощущаешь себя жужжащей мухой, летающей вокруг по необходимости.
Когда трава была зеленее, когда мы сильно боролись за каждый такт процессора, тратя на это наше время, которое мы тогда не очень ценили, все было в какой-то мере проще.
Если тебе нужна была фича, ты ее делал сам.
Или ты искал уже реализованную фичу, и прикручивал к своему коду.
Больше времени уходило на поиск. Не всегда можно было найти.
Сейчас все поменялось.
Подключение новой фичи чаще всего присоединяет к твоему коду 100500 дополнительных фиговин, которые мало того, что чаще не нужны, но и которые мешают запустить твой код.
Они подключаются по дефолту сами, и ты ищешь как их отключить. Но так как библиотеки постоянно меняются, это не так просто. Сколько раз подключал <подставь свой фреймворк>, ещё не разу не было одинакового кода. Постоянно меняются названия методов, их параметры, типы.
Раньше было просто. Возьмем для примера <подставь свой фреймворк>. Ты подключал и говорил ему, что нужно делать в первом случае, что во втором, что в третьем.
Сейчас же так просто не работает. Все стало сложнее. Ты указываешь доступный всем метод по старинке, но не тут то было. Клиенты получают в ответ фигу. Ты думаешь, что поменялся синтаксис, ищешь новые незадеприкейчаные методы (которых по количеству уже меньше, чем задеприкейчаных), но все равно клиенты получают фигу. Один и тот же код разрешает пользователям работать с одними запросами, но не разрешает с другими. Уверен, что это как-то объясняется. Просто подключается ещё куча бинов по дефолту, с доп параметрами по дефолту, и т.д. Идеология упрощения.
Но то, что прямо игнорируется команда разработчика, это уже перебор.
В геометрическом ядре C3D ранее был реализован алгоритм для построения срединных оболочек между эквидистантными группами граней. В данный момент завершен этап по расширению этой функциональности. Теперь в ядре есть возможность построения срединных поверхностей между произвольными поверхностями.
Вместе с описанием новой функциональности в этой статье отдельное внимание уделяется численным методам и подходам к поиску точек срединных поверхностей.
Всем привет!
Пишу этот пост, чтобы поделиться своим опытом и получить критику или советы от людей с большим опытом.
Мне 22 года, я из Латвии. По образованию я судовой механик, но уже около 4 лет увлекаюсь программированием. Долгое время это оставалось хобби: пробовал сайты, простые игры — но они не приносили настоящего удовольствия. Я считал, что в программировании нужно было разбираться ещё со школы, и долго не верил, что могу найти себя в этой сфере.
Переломный момент наступил, когда я заинтересовался системным программированием. Каждый раз, когда узнаю, как работает низкоуровневая часть ОС, у меня будто открывается новый мир. Особенно зацепила тема процессорного планирования: все говорят «железо, CPU, видеокарта», но на практике даже реализация планировщика процессов может заметно влиять на производительность.
Задача с LeetCode.
Дан массив слов words. Слово содержит латинские буквы в нижнем регистре a-z. Проверить пары смежных слов 
и удалить 
, когда 
и - анаграммы.
Найдем группы смежных анаграмм и оставим в массиве первую строку каждой группы.
