Библиотека C/C++ разработчика

Парсер C++ на своем DSL: попытка обогнать компилятор Проекты растут. Кодовая база растёт. Время компиляции растёт вместе с ними и переходит все границы разумного. В какой-то момент я решил: а что если попробовать написать свой компилятор? Пока только для разработки, не для прода. На замену Clang++/G++/CL.EXE. Эта статья — о первом шаге на этом пути. О парсере C++, который я написал на своём DSL специально сделанном для этого изначально. https://habr.com/ru/articles/1058150/ 📲 Мы в MAX #cpp #programming 👉 @cpp_lib

В C++ мы привыкли к удобным абстракциям вроде std::thread и std::jthread, но как именно они маппятся на операционную систему? Спойлер: ядро Linux вообще не знает, что такое «потоки» в классическом понимании. Для планировщика Linux существует только одна базовая абстракция - task (структура task_struct). Когда вы создаете новый поток, под капотом pthreads дергает системный вызов clone(). В отличие от привычного fork(), который полностью копирует состояние процесса, clone() позволяет битовыми флагами (CLONE_VM, CLONE_FILES и др.) жестко задать, какие ресурсы будут расшарены между родителем и потомком: адресное пространство, таблица файловых дескрипторов или обработчики сигналов. Как ядро не путается в потоках и процессах: • Каждый созданный поток получает свой уникальный PID (на уровне ядра это называется TID - Thread ID). Это позволяет планировщику (CFS) независимо распределять их по ядрам процессора. • Все потоки одного приложения объединяются в Thread Group и делят общий TGID (Thread Group ID), который равен TID самого первого потока (main). • Когда мы вызываем функцию getpid(), она на самом деле возвращает именно TGID. Поэтому, когда вы делаете kill -9 <PID>, ядро видит TGID и прибивает всю группу потоков разом, не оставляя зомби. По ссылке ниже - отличный хардкорный разбор архитектуры потоков в Linux: от системных вызовов до разделяемых состояний. Полезно для понимания того, как наши высокоуровневые многопоточные программы реально исполняются железом и ОС. 🔗 Читать статью: https://telegra.ph/How-Linux-Threads-Actually-Work-clone-Thread-Groups-and-Shared-Memory-07-15 📲 Мы в MAX #cpp #programming 👉 @cpp_lib

Путеводитель C++ программиста по неопределенному поведению Все начинается просто и незатейливо: обычный десятиклассник увлекается программированием, знакомится с алгоритмическими задачками, решения которых должны быть быстрыми. Узнает о языке C++, учит минимальный синтаксис, основные конструкции, контейнеры, решает задачи с предопределенным и всегда корректным форматом ввода и вывода, и горя не знает... В это же время, где-то в большом мире, матерые разработчики каждый день ругают то одни языки программирования, то другие. По самым разным причинам: не удобно, нет какой-то возможности, много лишних букв писать, ошибки в стандартной библиотеке... Но есть язык, который ругают за все и особенно за такую непонятную и таинственную вещь как неопределенное поведение (undefined behavior, UB). Спустя лет пять или шесть наш простой десятиклассник, горя не видавший в море оторванных от реальности программ, внезапно узнает, что тем самым горячо нелюбимым языком всегда был, остается и будет его C++. А потом еще в течение нескольких лет он наткнется на самые кошмарные и невероятные ужасы, поджидающие программистов на C++ почти на каждом шагу. Так и появится эта серия заметок, собирающая наиболее отвратительные примеры, на которые очень легко наткнуться при решении повседневных задач. Важно: этот сборник не является учебным пособием по языку и рассчитан на тех, кто уже знаком с программированием, с C++, и понимает основные его конструкции. https://github.com/Nekrolm/ubbook 📲 Мы в MAX #cpp #programming 👉 @cpp_lib

40 лет программирования на C++ и встраиваемых языков — Марк Гуидарелли, CppCast 409 / C++Weekly 541 Обязательно ознакомьтесь с проектом Марка: https://github.com/mcguidarelli/trix В этом месяце к Джейсону и Матье присоединяется Марк Гуидарелли, чтобы обсудить историю C++ и эзотерические языки программирования. Мы также поговорим о личном опыте разработки Марка и о том, что означало «слияние» до появления систем контроля версий! источник #cpp #programming 👉 @cpp_lib

Константин Осипов — Стратегии слияния (compaction strategies) в LSM-деревьях Стратегия слияний в LSM-деревьях — проблема, для которой сейчас не существует доказанного оптимального решения. RocksDB, Cassandra, CockroachDB реализуют целый ряд эвристик и предлагают пользователю многочисленные настройки по оптимизации под конкретные сценарии нагрузки. В докладе я попробую разобрать эту проблему в свете последних изменений в аналогичном алгоритме слияний в движке Vinyl для Tarantool и Picodata, который я реализовал. Разберу различные стратегии, настройки, и техники оптимизации. Коснусь последних статей по теме. В результате, надеюсь, у слушателей появится более целостная картина проблемной области и компромиссов, на которые идут разработчики движков хранения данных. источник 📲 Мы в MAX #cpp #programming 👉 @cpp_lib

👨‍💻Большинство разработчиков используют готовые средства для создания интерфейсов и редко задумываются, что происходит под капотом. Но именно понимание внутренних механизмов помогает создавать более гибкие, быстрые и управляемые приложения. 📆14 июля в 20:00 МСК приглашаем на открытый урок, где разберём, как создавать собственные элементы управления без сложных надстроек и лишних зависимостей. Вы узнаете, как обрабатывать действия пользователя, выводить графику на экран, создавать кнопки, текстовые поля и другие элементы интерфейса, а также организовывать их взаимодействие внутри приложения. Все подходы будут рассмотрены на практических примерах. 🏁Открытый урок проходит в преддверии старта курса «C++-разработчик. Продвинутый уровень». Зарегистрируйтесь, чтобы глубже понять устройство интерфейсов, задать вопросы эксперту и оценить возможности дальнейшего развития в C++: https://vk.cc/cZqKci Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

Курс по C++ и SFML Простые программы на C++ В статье мы напишем пару простейших программ на C++ и посмотрим, как происходит их компиляция. https://ps-group.github.io/ps1/lesson_cpp_1 Знакомство с SFML. Компьютерная графика. SFML (Simple Fast Multimedia Library) — это C++ библиотека для мультимедиа. В статье мы воспользуемся SFML для рисования фигур в окне. https://ps-group.github.io/ps1/lesson_sfml_1 Основной цикл программы. Анимация. В статье мы освоим паттерн Game Loop, а также научимся обрабатывать события мыши и клавиатуры. https://ps-group.github.io/ps1/lesson_sfml_2 Обработка событий. Интерактив. В статье вы освоите обработку событий мыши и клавиатуры в мультимедийных программах и научитесь писать функции на языке С++ https://ps-group.github.io/ps1/lesson_sfml_3 Соглашения о кодировании на C++ Соглашения о кодировании для курса по C++/SFML https://ps-group.github.io/ps1/cxx_coding_style Комплексные задачи. Котик следует за мышкой В этой практике вы начнёте по шагам решать комплексные задачи, двигаясь от математической модели и псевдокода к готовой программе https://ps-group.github.io/ps1/sfml_workshop_1 Массовые столкновения На этом занятии вы научитесь программировать игры уровня Бильярда или Arkanoid https://ps-group.github.io/ps1/sfml_workshop_2 Ещё одна практика на SFML На этом занятии вы освоите более гибкие приёмы работы с SFML: виртуальную камеру, рисование произвольных фигур, проверку столкновения https://ps-group.github.io/ps1/sfml_workshop_3 Основной проект курса: 2D игра Цель проекта - самостоятельно написать комплексную программу, клон небольшой игры https://ps-group.github.io/ps1/project Задание | Спецификация проекта в виде MindMap Чтобы составить видение проекта-игры, нужно визуализировать. Сделать это поможет MindMap. https://docs.google.com/document/d/1Ki6DlbhDrZHskC6LED88FHeX8m-Se3-MrTpjwKYlcDk/edit?usp=sharing Задание | План проекта в виде RoadMap Чтобы справиться с известным проектом в известные сроки, нужно составить план действий. Сделать это поможет RoadMap. https://docs.google.com/document/d/1zdW81SLmgVf3ZXyMwXkOXxIwOzBzkTTvi4TTMLdUw_E/edit Пишем клон игры PacMan слой за слоем В этой коллекции примеров слой за слоем на C++/SFML воссоздаётся урезанный клон игры PacMan https://github.com/ps-group/sfml-packman Схема оценки проекта-игры В таблице записаны критерии оценки и примеры оценивания различных игр https://docs.google.com/spreadsheets/d/1n7OzeQEDujPDboW3dFn4M4iXhcPvlCR7FQbPRSE4jwM/edit?usp=sharing 📲 Мы в MAX #cpp #programming 👉 @cpp_lib

std::expected в C++23: гайд по миграции с исключений на функциональный error handling Исключения удобны, пока ошибки не становятся обычной частью логики. В C++23 для таких случаев есть std::expected: он явно показывает в сигнатуре, что функция вернёт либо результат, либо ошибку. Разберём, как перейти к этому подходу без переписывания проекта с нуля. https://habr.com/ru/companies/otus/articles/1054592/ 📲 Мы в MAX #cpp #programming 👉 @cpp_lib

🇷🇺 Разбираешься в радиочипах, оптике и связи? Забери до 1 000 000 рублей за свои инженерные навыки на турнире «Дронкон» 🇷🇺 «Сталинские Соколы» открывают регистрацию на 4-й Всероссийский турнир «Дронкон», который пройдет с 22 по 26 августа. Турнир пройдет по направлению: - Инженерное дело: навыки программирования, сборка электронного оборудования, беспроводная связь, оптические системы + стратегия «Битва Дронов»; Призовой фонд для победителей: 🥇место – 1 000 000 рублей 🥈место – 700 000 рублей 🥉место – 500 000 рублей Награда за 4-8 места - 100 000 рублей Пройди заочный онлайн-этап и получи путевку на очный этап турнира в Республику Татарстан! Перелет, питание, проживание - за счет организаторов. 🇷🇺 Подать заявку и узнать подробности 🇷🇺

👨‍💻 Два в одном: валидация и вызов в Control Flow Guard (CFG) Рэймонд Чен (Raymond Chen) в своем блоге The Old New Thing поделился интересными деталями реализации механизма Control Flow Guard в Windows. Обычно CFG работает в два этапа: сначала мы вызываем функцию вроде LdrpValidateUserCallTarget для проверки указателя, и если всё в порядке, возвращаемся и делаем вызов. Но существует и комбинированная версия, которая не просто проверяет указатель, но и сразу же делает по нему переход (jump). 🤔 Зачем это нужно и в чем подвох? Раз уж после валидации почти всегда следует вызов, объединение операций кажется логичным шагом для оптимизации. Но здесь кроется проблема: для такого трюка приходится менять соглашение о вызовах (calling convention). Регистры, которые использует функция валидации, ни в коем случае не должны пересекаться с регистрами, в которых лежат аргументы для итоговой функции. 🔧 Как это реализовано на уровне ассемблера: 🔹 x86-64: Обычная функция-валидатор принимает адрес в rcx и использует rax и rdx как временные регистры. Комбинированная версия принимает адрес в rax, использует r10 и r11 для своих расчетов, а в конце просто делает jmp rax. Все исходные параметры целевой функции остаются нетронутыми! 🔹 AArch64: Логика абсолютно та же. Обычная версия принимает адрес в x15, а комбинированная - в x9, завершаясь инструкцией br x9 вместо классического ret. Кстати, есть и приятный микро-бонус при обработке ошибок: если указатель оказывается «битым», комбинированной функции не нужно тратить инструкции на перекладывание адреса в нужный регистр перед прыжком в блок ошибки - плохой адрес уже находится там, где нужно (rax или x9). 🔗 Оригинальная статья и листинги дизассемблера: https://devblogs.microsoft.com/oldnewthing/20260708-00/?p=112510 📲 Мы в MAX #cpp #programming 👉 @cpp_lib