Казалось бы, современный С++ дает столько возможностей… Давайте попробуем препарировать всю эту необъятную мощь, начав с первого шага в любом языке программирования — «Hello World».
Как реализации компиляторов встречают новичка, впервые написавшему свои первые строчки кода?
Недавнее обсуждение опасности дверей в геймдеве напомнило мне о баге, вызванном дверью из игры, о которой вы, возможно слышали — Half Life 2. Усаживайтесь поудобнее, мы начинаем.
Когда-то я работал в Valve над проектами виртуальной реальности. Это было в 2013 году, примерно когда появился Oculus DK1. Мы с Джо Людвигом решили, что лучше всего можно понять, как будет работать VR в контексте реальной игры, портировав в неё реальную игру.
Мы выбрали Team Fortress 2 (причина этого — отдельная история, которой я не хочу здесь касаться). В TF2 использовался движок Source 1, и так получилось, что двумя другими играми Valve, тоже построенными на этом движке, были Half Life 2 и Portal 1. Поэтому побочным эффектом стало то, что они тоже будут работать в VR.
Точнее, Portal 1 «работал», однако все трюки с перспективой при прохождении через портал вызывали настоящую тошноту, поэтому играть в это было практически невозможно.
Зато HL2 игрался достаточно неплохо. Джо потратил довольно много времени на то, чтобы уровни с лодкой работали прилично.
Привет! На связи Антон Полухин из Техплатформы Городских сервисов Яндекса. На днях в Кройдоне состоялась встреча международного комитета по стандартизации языка программирования C++, в которой я принимал активное участие. В этот раз (как и в прошлый), всё внимание было сосредоточено на C++26 и… теперь он готов! Осталось пройти формальные этапы в вышестоящих инстанциях ISO, и мы получим C++26 который заслужили. В нём будут:
• reflection,
• контракты,
• SIMD,
• линейная алгебра,
• расширенные возможности сonstexpr,
• hardening,
• Hazard Pointer и RCU,
• #embed,
• executors,
• и многие другие полезные вещи.
Каждую секунду в дата-центры Cloudflare в 330 городах отправляется 84 миллиона HTTP-запросов. Из-за этого даже самые редкие из багов возникают достаточно часто. На самом деле, именно наши масштабы позволили нам недавно обнаружить в компиляторе Go на arm64 баг, вызывающий состояние гонки в генерируемом коде.
В этом посте мы расскажем о том, как впервые столкнулись с багом, исследовали его и докопались до его первопричины.
В одном из моих докладов по ассемблеру я показал список из 20 самых часто исполняемых команд на среднем десктопе x86 с Linux. Разумеется, в этом списке были привычные mov, add, lea, sub, jmp, call и так далее; неожиданным стало включение в него xor — «eXclusive OR». В эпоху, когда я занимался хакингом на 6502, наличие XOR было почти абсолютно точным указанием на то, что найдена часть кода, связанная с шифрованием, или какая-то подпрограмма обработки спрайтов. Поэтому удивительно, что машина с Linux, просто занимающаяся своими делами, выполняет такое количество этих команд.
Но потом мы вспоминаем о том, что компиляторы любят генерировать xor при присвоении регистру нулевого значения.
Привет! На связи Антон Полухин из Техплатформы Городских сервисов Яндекса, и сейчас я расскажу о софийской встрече Международного комитета по стандартизации языка программирования C++, в которой принимал активное участие. Это была последняя встреча, на которой новые фичи языка, с предодобренным на прошлых встречах дизайном, ещё могли попасть в C++26.
И результат превзошёл все ожидания:
Если бы Кардинал Ришелье был программистом, он бы сказал: «Дайте мне шесть строк кода, написанных рукой самого профессионального C-программиста в мире, и я найду в них лазейку для вызова неопределённого поведения.
Никто не может написать безошибочный код на С или C++. И я говоря об этом как человек, который пишет на этих языках почти каждый день около 30 лет. Я слушаю подкасты по C++. Я смотрю выступления про C++ на конференциях. Мне нравится читать и писать на этом языке.
C++ послужил нам сполна, но на дворе 2026 год, и современная рабочая среда явно отличается от среды 1985 (C++) или 1972 (С).
И я далеко не первый, кто об этом заговорил. Помню ещё с десять лет назад читал статью какого-то известного человека, в которой он утверждал, что использование C++ вполне обоснованно можно подвести под нарушение закона Сарбейнза-Оксли (SOX). И хотя с остальной его критикой я не был согласен (как и с тем, что он путал «its» и «it’s»), конкретно с этим пунктом я никогда не спорил.
Мало того, со временем я всё больше убеждался в его истинности. На деле в С для возникновения неопределённого поведения (undefined behaviour, UB) есть гораздо больше возможных причин, чем вы могли предполагать.
Все знают, что двойное освобождение памяти, её использование после освобождения, выход за границы объекта (например, массива) и чтение неинициализированной памяти — это UB. Как ни крути, но в контексте работы с памятью C и C++ безопасными не назовёшь. Тем не менее даже эти ошибки продолжают совершаться повсеместно раз за разом.
Проблема: когда из-за «оптимизации» код замедляется
Начнём с ситуации, в которой могут спотыкаться даже опытные разработчики. Допустим, вы написали на C++ следующий код, который выглядит совершенно нормальным:
Кто угодно может пнуть мёртвого льва. Мёртвый лев не рыкнет на наглеца. Мёртвый лев не откусит ему ногу «по самое не хочу», хотя стоило бы. Лев мёртв, и теперь его может пнуть каждый ишак, что конечно же не показывает превосходство ишака над львом. Эта статья будет полна негодования и ненависти. Кровь ещё закончила кипеть от негодования. Но, разумеется, помимо эмоций будут и сухие объективные факты, немножко исследования и расстановка точек над i. В интернете кто-то не прав... опять...
Существует целый ряд инструментов, технологий и вообще вещей, которым по какой-то непонятной вселенской несправедливости не повезло: нашлась масса непонятных людей, которые по какой-то необъяснимой причине начали распускать про эти инструменты/технологии/вещи разные небылицы, идиотские фейки, слухи и прочий порочащий репутацию «компромат». Можно не переживать, если речь идёт о технологии, которая находится «на пике» — у неё будет большое community и правда восторжествует. Совсем другое дело, когда речь идёт о чём-то, что далеко не на пике, чья минута славы в прошлом (возможно даже давно в прошлом) — здесь мёртвый «лев» не может дать сдачи, и что самое обидное, что в какой-то степени «лев» сейчас мёртв отчасти и потому, что ещё при его жизни началось необоснованное распространение всяких бредовых поверий и мифов про него. И сегодня речь пойдёт об одном из таких случаев.
Зачем вообще компилировать TypeScript?
Есть большой проект, с кодовой базой в два миллиона строк на C++. Ядро на плюсах, поверх него работают несколько UI: десктопный интерфейс, веб и мобильное приложение. В какой-то момент проект упирается сразу в две проблемы. Первая — лицензионные ограничения: новые версии Qt, на которых мог бы жить десктопный интерфейс, становятся недоступны по санкционным причинам. Вторая — скорость разработки: UI давно хотелось писать быстрее.
Возникает логичный вопрос: что, если взять лучшие, максимально автоматизированные инструменты из веба и перенести их в мир нативных приложений без браузера и лишних прослоек? Ключевая цель — обеспечить возможность вызова C++-код из TypeScript с возвратом результата без промежуточных интерпретаторов.
Меня зовут Владимир Цышнатий @Tsyshnatiy. Я занимаюсь разработкой более 15 лет, мой основной профиль — C++. Помимо этого меня увлекают технологии на стыке разных миров. В том числе идея, лежащая в основе этой статьи: дать возможность писать на TS как на нативном языке.
Интересно узнать, как мы это делали и что получилось? Детали под катом!
Привет! На связи Антон Полухин из Техплатформы Городских сервисов Яндекса. Сегодня я расскажу о ноябрьской встрече Международного комитета по стандартизации языка программирования C++, в которой принимал активное участие. Это была первая из встреч, связанных с «полировкой» C++26. Другими словами, новые фичи C++ пока не появятся — комитет должен только проработать замечания всех стран-участников, включая наши замечания от России.
Однако от плана немного отступили и втащили некоторые новинки как ответы на пожелания участников комитета: std::integer_sequence оброс новой функциональностью, а std::format научился в constexpr.
Помимо этого, поправили множество багов, перековыряли связку Hardening + Contracts, внесли улучшения во многие части стандартной библиотеки.
Всем привет! Сегодня продолжаем нырять в глубины питона, но в другом формате.
В субботу (20 сентября 2025го) у нас завершилась наша первая бесплатная конференция сообществ Нижнего Новгорода.
На ней у нас был шикарный Python-трек с очень глубокими докладами от наших любимых хабравчан про устройство разных частей интерпретатора и несколькими вводными на смежные темы. Выступали и новички, и «старички» :)
Как по мне — вышло отлично.
Под катом будет полный список докладов и материалов, заходите и смотрите!
Если кратко, то цель: компилятор некоторого подмножества языка Си на C++, который работает в compile-time. Компиляция будет происходить в кастомный байт-код для дальнейшего выполнения в ВМ уже в рантайме.
Делюсь опытом кросс-компиляции и запуска консольной программы на Go из-под Linux в другие ОС: Android, Windows. Для сетевых сервисов, утилит, криптопрограмм и других решений без GUI это может быть весьма полезно.
В наше время программирование стало очень доступным из-за развития инструментов и языков. Написать «привет, мир» может практически каждый, а количество фреймворков для JavaScript уже воспевается в шутках. Теперь, чтобы выделиться и впечатлить друзей и коллег, нужно спускаться глубже. Придумаем свой язык шуточный программирования!
В этой статье кратко рассмотрим базу компиляторов и мемные эзотерические языки программирования. В конце придумаем свой язык и попробуем его реализовать.
Это упрощенная статья, которая расширит ваш кругозор, а у некоторых вызовет интерес и любопытство погрузиться в тему.
Привет!
Хочу вместе с вами разобрать, как же код на Rust превращается в готовый исполняемый файл. Мы пишем программу, например, fn main() { println!("Hello, Habr!"); }, компилируем, и на выходе получаем бинарник. Что происходит под капотом компилятора Rust в этот момент? Давайте аккуратненько заглянем внутрь этого таинственного процесса.
Во всех устройствах YADRO, будь то системы хранения данных, серверы или коммутаторы, есть система BMC, через которую администраторы гибко управляют серверами.
Мы поддерживаем продукты в конкурентоспособном состоянии и выпускаем обновления с исправлениями багов, поддержкой новых стандартов безопасности и новой функциональностью. Но чем больше новшеств, тем больше места бинарный код занимает на накопителе с прошивкой устройства. На старых платформах уже нет возможности расширить накопитель, поэтому мы ищем, как уменьшить прошивку, сохранив всю нужную функциональность.
Меня зовут Максим Гончаров, и я расскажу, как мы оптимизировали кодовую базу на C++ по размеру конечного образа, чтобы новые фичи были доступны на всех уже работающих у заказчиков серверах.
Антонио Куни — инженер, давно занимающийся повышением производительности Python, а также разработчик PyPy. Он провёл на EuroPython 2025 в Праге презентацию «Мифы и легенды о производительности Python». Как можно догадаться из названия, он считает многие общепринятые сведения о производительности Python как минимум вводящими в заблуждение. На множестве примеров он показал, где, по его мнению, таятся истинные проблемы. Инженер пришёл к выводу, что управление памятью в конечном итоге наложит ограничения на возможности повышения производительности Python, но у него есть проект SPy, который, возможно, станет способом реализации сверхбыстрого Python.
Он начал своё выступление с просьбы: «Если вы считаете Python медленным или недостаточно быстрым, поднимите руку»; поднялось много рук, в отличие от презентации на PyCon Italy, где руку не поднял почти никто из присутствующих. «Совершенно другая аудитория», — сказал он с улыбкой. Антонио уже много лет работает над производительностью Python, он общался с множеством разработчиков на Python и слышал кучу устоявшихся мифов, которые захотел развеять.
Недавно мы переделали наши внутренние инструменты, визуализирующие компиляцию JavaScript и WebAssembly. При работе оптимизирующего компилятора Ion мы теперь можем генерировать интерактивные графы, демонстрирующие, как конкретно обрабатываются и оптимизируются функции.
Вы можете сами поэкспериментировать с этими графами в оригинале статьи. Просто введите какой-нибудь код на JavaScript в функцию test, и наблюдайте за созданием графа. Также там можно щёлкать и перетаскивать граф, менять масштаб при помощи колеса мыши с зажатым Ctrl и перетаскивать ползунок вниз, чтобы изучить процесс оптимизации.
В процессе экспериментов обратите внимание на то, насколько стабильна схема графа даже при изменении размеров блоков и добавлении новых структур. Попробуйте нажать на заголовок блока, чтобы выделить его, а затем перетащить ползунок, и наблюдайте за тем, как меняется граф, а блок остаётся на месте. Или нажмите на номер команды, чтобы подсветить её и следить за ней между проходами.
Разумеется, мы не первые, кто начал визуализировать внутренние графы компиляторов, и не первые, кто сделал их интерактивными. Но меня не устраивали результаты работы популярных инструментов наподобие Graphviz и Mermaid, поэтому я решил создать алгоритм специально под наши потребности. Получившийся алгоритм прост, быстр, создаёт на удивление высококачественный вывод и его можно реализовать в менее чем тысяче строк кода. В этой статье я объясню алгоритм и конструкторские решения, лежащие в его основе.
В наше время разработчики уже не так беспокоятся о размере приложений. Некоторые простейшие приложения требуют под 200-300 МБ, а игра вообще может весить более 100 ГБ. Я уже не говорю про "Hello World", который иногда занимет под 180-260 КБ!
К счастью, есть возможность сократить размер приложения. О мусоре в exe'шнике и о способах его удаления написано в этой статье.
