Приветствую, Хабравчане!
Решил сделать цикл статей по написанию на С++, различных небольших программ. Под новые и старые ОС. Мне кажется мы стали забывать как раньше программировали:) Для себя определил несколько важных критериев.
В своей предыдущей статье [перевод на Хабре] я говорил о множестве недостатков C++, которые, по сути, устранил Rust. Благодаря этому код теперь легко использовать правильно и сложно использовать неверно. Я не говорил о безопасности по памяти, просто привёл пример того, что пользователь функции не может случайно поменять местами аргументы количества и цены.
На написание статьи меня вдохновил доклад Мэтта Годболта о том, как можно сделать интерфейсы C++ более надёжными: Correct by Construction: APIs That Are Easy to Use and Hard to Misuse. Вам стоит его посмотреть!
В той статье я сказал, что Rust гораздо лучше помогает разработчику, возможно, благодаря тому, что у него были десятки лет, чтобы учиться. В конце концов, первая версия C++ была выпущена в начале 80-х, а Rust — в начале 2010-х. Если дать C++ несколько десятков лет для обучения, то, разумеется, появятся новые структуры, которые будут обладать высоким качеством и которые сложно использовать неправильно.
Но так ли это?
Привет, Хабр!
В этой статье рассмотрим Range-v3 — библиотеку, которая изменила подход к обработке последовательностей в C++ и стала основой для std::ranges в C++20.
Range-v3 — это библиотека, расширяющая стандартную библиотеку C++ возможностью работать с диапазонами вместо begin()/end(). В основе идеи лежат три концепции.
Вы хотите идти в ногу со временем и перевести ваш проект на полиморфные аллокаторы? Вас не могут отговорить от этого даже затраты на виртуальные вызовы? Тогда вы просто обязаны знать о нюансах с лайфтаймом, и почему нельзя просто взять и поменять свои контейнеры на аналоги из пространства имён pmr.
Большинство SIMD инструкций узконаправленны, например применяют бинарную операцию параллельно для нескольких чисел, упакованных в длинный регистр. Применение таких операций прямолинейно и в большинстве случаев компилятор сам оптимизирует код с использованием таких инструкций. Например компилятор легко соптимизирует таким образом проверку несложного предиката на массиве или например суммирование элементов массива. Есть однако и более универсальные инструкции, в частности довольно много всякого рода манипуляций с битами внутри регистра. В этой статье хочу рассказать о двух таких инструкциях: уже давно присутствующей PSHUFB и довольно новой GF2P8AFFINEQB, расскажу как с их помощью делать побайтовую обработку общего вида и приведу пару примеров с известными операциями такими как popcount, подсчет четности, разворот битов числа.
Вот уже последние лет 10 одна половина человечества стремительно проваливается в пучину бесполезного повторения одного и того же с каждый раз всё худшими показателями, а вторая половина запрещает абы что.
в github, vscode и windows абсолютно каждое обновление уже несколько лет связано только с "ИИ", при этом ни один реальный показатель этих программ не стал лучше. В каждый поисковой запрос встроен ИИ, а качество поиска в гугле стало хуже (считал ли кто-то, сколько электричества ушло на это?)
Компилятор go переписывают на go, JavaScript существует больше 20 лет, появился TypeScript, но он... Всё также компилируется в обычный JavaScript, даже более объёмный, чем написанный вручную. До сих пор все оптимизации передачи джаваскрипта по сети не пошли дальше удаления пробелов из исходного текста, хотя на поверхности лежит трансляция TypeScript в бинарный JS, который позже напрямую быстрее интерпретируется и тратит в разы меньше сетевого трафика
Недавно я зашёл в браузер хром и решил поискать небольшую фразу в довольно объёмном файле.
Прежде чем рассказать про архитектуры игровых движков, я подумал, что будет полезно немного рассказать о том, как я понимаю архитектуру ПО и как это связано с играми. Во-первых, они (архитектуры) есть, чтобы бы там не врали про игрострой. Во-вторых, их оказывается больше одной. Это, возможно, поможет вам понять, почему остальные статьи написаны в таком порядке, или без какого-то порядка. В худшем случае, когда вас втянут в спор о том, насколько отвратительны (или, наоборот, потрясающе гениальны) отдельные игровые движки и их архитектуры, у вас будет пара аргументов и понимание что к чему.
Символично, что статья про архитектуру игрового движка появилась после того, как было рассказано про строки, мультипоток, применение алгоритмов: просто оно так и в жизни получается, мы сначала пишем код, редактор, игру - костяк проекта обрастает мясом, и тут нас догоняют проблемы, на которые все забивали, потому что надо было выдать хоть что-то похожее на работающий вариант. Но от того, что мы забивали на проблемы и заметали их под коврик беклога, проблемами быть они не перестали.
Вы не получите из статьи знаний об аллокаторах, контейнерах, или математике, стоящей за физикой игры. Так-же я не ставлю целью научить вас, как применять A* разбиение в поиске пути неписей или моделировать реверберацию комнаты. Вместо этого есть размышления о коде между всем этим. И даже не столько про написание кода, сколько о его организации.
В разработке игр динамические и статические массивы являются основным инструментом при работе с набором объектов, буду дальше называть их vector. Вы можете подумать про разные map, set, и другие ускоряющие структуры, но их тоже предпочитают делать поверх векторов. Почему так? Вектора просты для понимания, удобны для большого числа задач, особенно там, где объём данных заранее неизвестен или примерно известен. Но как вы понимаете, за все надо платить, и расплачиваться приходится производительностью, которой, как обычно, всегда не хватает. Так что, использование динамических массивов имеет свои ограничения и особенности.
Тема безопасного и эргономичного взаимодействия между Rust и C/C++ была популярна на конференции RustConf 2025, состоявшейся в Сиэтле, штат Вашингтон. Чендлер Каррут выступил с презентацией, в которой представил различные способы взаимодействия между Rust и Carbon — экспериментальным языком, который можно условно обозначить как «(C++)++». Он резюмировал, что, пусть возможности стыковки Rust с другими языками со временем расширяются, в обозримом будущем не стоит ожидать, что будет полноценно решена проблема его взаимодействия с C++. Поэтому как раз появляется ниша для Carbon, который может предложить иной подход для постепенного совершенствования существующих проектов на C++. Вот слайды к его презентации — для тех, кто хотел бы изучить код его примеров более подробно.
Новый стандарт C++, C++23, впервые с C++11 расширил всем привычную линейку контейнеров: помимо знакомых array, vector, (unordered_)set, (unordered_)map и прочим в нее теперь входят непонятные flat_set, flat_map, flat_multiset и flat_multimap. Ответим на вопросы, что это за контейнеры, когда они могут быть полезны, сравним дизайн стандартизированных «плоских» контейнеров с дизайном плоских контейнеров из Boost и ETL и, конечно, произведём замеры и сравним производительность flat_ и не flat_ контейнеров.
Иногда надо создать функцию, которая должна быть и доступна в blueprints, и адаптироваться под входные данные. Особенно это касается wildcard.
Можно прибегнуть к ручной прописке рефлексии UFUNCTION. Однако, у этого есть свои ограничения. Для таких случаев в движке есть довольно старый класс – UK2Node.
Рассматриваем различные «приколюхи» из C++20 на примере хеш‑мапы!
В статье я разобрал разные способы реализации тех или иных методов в хеш-мапе, так же провел небольшой анализ над ними. Статья является научно-просветительской и немного исследовательской.
Всю свою жизнь я обходил самоделки. Не привлекало, да и на непосредственной работе вполне хватало сложных программистских и инженерных задач. Но любовь к сыну сподвигла взяться за один DIY-проект.
Дело в том, что я давно люблю и ценю изобразительное искусство. И также люблю изучение истории (и вообще считаю, что не программированием единым должен жить человек). И я подумал, что изучение истории и живописи можно слить в единый флакон – будет и не скучно, и полезно. Особенно полезно подрастающему школьному и дошкольному поколению. Я захотел электронную картину – чтобы выглядела как картина, а изображения бы настраивались мной, автоматически сменяясь по таймеру. Каждый день – новая картина. Каждый день – повод обсудить с сыном, как видели этот мир художники 200, 300, 500 лет назад, и вообще, а что это за разновидность палаша, аркебузы или фрегата запечатлел здесь художник. А здесь какое важное для мировой истории событие показано?
Изучив рынок электроники, я понял, что подходящего под мои требования продукта просто не найти (хотя отдаленно похожие есть, конечно). Потому я прикинул доступную мне элементную базу, расчехлил клавиатуру и принялся писать код. В итоге получилось десктоп-приложение на С++/Qt, которое я закинул на мини-ПК под Windows, а сама картина представила собой обрамленный в багет сенсорный дисплей на 18,5 дюймов с прекрасной цветопередачей. По итогу заинтересовался не только сын, но, неожиданно, и жена.
Сейчас телеграм боты крайне популярны, казалось бы, если всё так просто и есть спрос, то наверняка уже сотни библиотек для удобного создания ботов?
Вкратце - нет, если вы захотите написать телеграм бота, то вы (были) вынуждены делать это на python. Библиотеки на...
Привет, Хабр! На связи Марат Гаянов, я занимаюсь исследованием безопасности. В сфере моих профессиональных интересов эксплуатация уязвимостей, реверс-инжиниринг и фаззинг. В этой статье я хочу рассказать об одном баге, точнее, о его эксплуатации.
Эксплуатация уязвимости типа use after free в ядре Windows и без того непростая задача, но когда к этому добавляется состояние гонки (race condition), сложность возрастает на порядок. CVE-2025-29824 — наглядное тому подтверждение, однако, как будет продемонстрировано ниже, создание рабочего эксплойта для нее — достижимая цель.
Давайте продолжим обсуждение самой неоптимизированной в мире 32-битной библиотеки для работы с плавающей запятой TinyFloat. Библиотека написана на C++ и намеренно избегает встроенных типов плавающей запятой, полагаясь исключительно на 32-битные целые числа. Цель состоит в том, чтобы сделать код максимально читабельным — без бит-хаков и хитроумных уловок.
Библиотека пишется в рамках борьбы с неграмотностью населения, поэтому, я хочу иметь подробную документацию о том, что происходит «под капотом». Оказалось, что лучший способ документировать код C++ — это полностью переписать его на Python :-)
Тема на сегодня - как работает сложение чисел с плавающей точкой и соответствующие подводные камни. Это третья статья из цикла, первые две читать тут и тут.
Код некоторых модулей Erlang/OTP старше, чем большинство современных junior-разработчиков. Эти файлы — настоящие цифровые патриархи, десятилетиями обеспечивающие работу банковских транзакций, телефонных сетей и систем обмена сообщениями. Мы решили заглянуть под "капот" этого языка-долгожителя, чтобы проверить, что именно скрывается в строках, на которые сегодня полагаются миллионы пользователей. А вот что мы нашли, узнаем в этой статье.
Всем привет!
Пишу этот пост, чтобы поделиться своим опытом и получить критику или советы от людей с большим опытом.
Мне 22 года, я из Латвии. По образованию я судовой механик, но уже около 4 лет увлекаюсь программированием. Долгое время это оставалось хобби: пробовал сайты, простые игры — но они не приносили настоящего удовольствия. Я считал, что в программировании нужно было разбираться ещё со школы, и долго не верил, что могу найти себя в этой сфере.
Переломный момент наступил, когда я заинтересовался системным программированием. Каждый раз, когда узнаю, как работает низкоуровневая часть ОС, у меня будто открывается новый мир. Особенно зацепила тема процессорного планирования: все говорят «железо, CPU, видеокарта», но на практике даже реализация планировщика процессов может заметно влиять на производительность.
Привет Хабр! В этой статье я хотел поговорить о теме вечных конфликтов разработчиков на C++ и Rust. Стоит ли того система управления памятью в Rust или все-же это бестолковый механизм стремящийся составить конкуренцию родному методу?
Систему управления памятью я разберу, а вот выводы остаются уже за вами.
Когда я начал работать с Asio и изучал документацию библиотеки, прочитал мнение, что доку писали «для роботов». Описание каждого концепта, функции или особенности приводится лишь однажды, без перекрестных ссылок и других удобных для разработчика деталей. Документация составлена так, что понять ее может разве что машина, «просканировав» текст целиком.
Я подумал, что было бы здорово написать статью, которая служила бы введением в библиотеку. Статью, которая помогла бы начать пользоваться Asio, даже если раньше вы с ней не работали. Что получилось, читайте под катом.
