Тема неопределённого поведения (UB) в языке C++ освещается и обсуждается многие годы, но это не значит, что она исчерпала себя. Это плата, которую программисты отдают за эффективные оптимизации кода, такие как удаление ряда проверок.
C++ - опасный инструмент, и не помешает лишний раз напомнить, как правильно держать его в руках. Причём с приходом инструментов вайб-кодинга ситуация, скорее всего, даже ухудшится, так как станет ещё сложнее удерживать неопределённое поведение под контролем. В докладе обсудили эту тему, заглянув в будущее.
Что такое LDL? Это графическая библиотека с единым API для всех систем как старых, так и новых.
Раньше я писал её на C++98, что давало хорошую портабельность. Но сейчас я пересмотрел многие тезисы, которые декларировал на GitHub, чтобы наконец добраться до первого релиза.
Новая стратегия
Я решил выпускать релизы без реализации полного функционала (графика, звук, шрифты и т.д.) постепенно, итеративно.
Перешёл на C89 для максимальной переносимости. Это не только DOS или Windows 3.x, но и старые системы вроде Solaris, PlayStation 1 и другие.
Для первого релиза реализую минимальный базовый функционал: графику (OpenGL, Vulkan), окна и события. По возможностям аналог GLFW.
С каждым следующим релизом буду добавлять: 2D-рендер, звук, шрифты и прочее.
Лицензия и целевые платформы
Лицензия меняется на LGPLv3.
На старте поддерживаются Windows и Linux.
Качество и инструменты
При разработке использую:
AddressSanitizer (ASan)
UndefinedBehaviorSanitizer (UBSan)
Различные анализаторы кода
Я считаю, что такая стратегия полезнее, чем годами доводить библиотеку до версии 1.0 в офлайн-режиме.
Примеры и бэкенды
Добавлю десятки примеров с OpenGL 1.x, OpenGL 3.x и Vulkan.
Буду добавлять бэкенды для LDL: не только под ОС, но и поверх других графических библиотек — SDL, SFML, GLFW и т.д.
API остаётся единым для всех бэкендов.
Это позволит сразу добавить поддержку звука и шрифтов (через бэкенды), а в нативных версиях реализовывать их позже.
2D-рендер без границ
Одной из главных задач LDL я вижу создание единого 2D-интерфейса, который стирает различия между поколениями графики.
Вам не нужно думать о том, что находится в системе: современная видеокарта с Vulkan, старый ускоритель с OpenGL 1.2 или вообще только центральный процессор (Software Rendering).
Единый интерфейс: Вы используете одни и те же команды для рисования пикселей, линий и спрайтов.
Адаптивность: LDL сам выберет наиболее эффективный способ вывода изображения. На современной системе это будет аппаратное ускорение, а на «железе» без видеокарты оптимизированный программный растеризатор.
Визуальная честность: Ваш визуальный стиль останется неизменным, на чем бы он ни запускался. Это дает возможность делать игры и приложения, которые выглядят и работают одинаково и на ретро-ноутбуке, и на современном мониторе.
Философия: Машина времени в вашем коде
Зачем тратить силы на поддержку систем, которые многие считают «трупами»?
1. Борьба с цифровым забвением
Современный софт живет 3–5 лет. Мы выбрасываем железо не потому, что оно сломалось, а потому, что софт стал слишком тяжелым и ленивым. LDL — это протест против «запланированного устаревания». Я хочу, чтобы код, написанный сегодня, мог дышать в железе любой эпохи.
2. Инженерный аскетизм
Когда у тебя гигабайты памяти, ты перестаешь ценить каждый байт. Написание библиотеки под C89 для слабого железа — это духовная практика для программиста. Это возвращение к искусству находить изящные решения в условиях жестких ограничений. Каждый сэкономленный такт процессора — это дань уважения инженерам прошлого.
3. Преемственность поколений
Мы стоим на плечах гигантов, но часто забываем их имена. LDL сохраняет возможность для диалога между эпохами. Это инструмент, который позволяет современному разработчику почувствовать «металл» старых машин, не теряя связи с современными технологиями вроде Vulkan.
Итог
LDL — это Little Directmedia Layer. Он маленький не потому, что слабый, а потому, что в нем нет ничего лишнего. Это попытка создать код, который будет принадлежать не конкретной версии ОС, а истории программирования в целом.
Один API. Один код. Тридцать лет компьютерной истории.
Всё, что нужно знать для начала работы в PVS-Studio
Статический анализатор PVS-Studio — это инструмент для поиска ошибок в коде на протяжении всего жизненного цикла проекта. В новой статье разберём основные особенности анализатора PVS-Studio, сценарии и варианты анализа, а также узнаем всё, что нужно знать для начала работы с инструментом.
Сравнивал разные методы сделать call-once (а точнее инициализацию синглтона) - далее небольшие заметки.
Итак, нам нужно создать какой-то объект, пусть даже что-то нетривиальное (для определённости можно представлять что мы хотим прочитать данные из файла/эмбеддет ресурсов и разложить эти данные в хеш-мапу для будущих чтений). Рассмотрим следующие варианты:
статичный глобальный объект, вычисление вызывается в конструкторе
статичный глобальный объект + std::call_once
статичный локальный объект в функции, вычисление вызывается в конструкторе
Чтобы в годболте видеть что и где вызывается - определяем тип имеющий только объявления методов (это заставит компилятор ставить явный call)
struct TSomeExternal {
TSomeExternal(int);
~TSomeExternal();
int DoCalc();
char Data[60]; // просто чтобы было проще увидеть
};
Особенности первого варианта:
вычисление "до main"
неконтролируемый порядок инициализации глобальных ответов => нельзя иметь зависимости между такими объектами
вычисление только в рамках 1 потока
уникальный плюс: нет проверок "на горячем цикле" - при обращении к объекту вызывающая функция может считать что данные уже готовы (но именно этот плюс стоит нам второго пункта)
В годболте можно посмотреть на func1 - видно что она скомпилилась просто в забор поинтера, и call
TSomeExternal GlobalValue(7);
int func1() {
int x = GlobalValue.DoCalc();
return x + 14;
}
Также видно что были порождены - указание что нужно разместить объект
GlobalValue:
.zero 60
А также _GLOBAL__sub_I_example.cpp - там видно, что вызывается конструктор, и регистрируется указатель на деструктор в пост-колбеках (__cxa_atexit)
Второй вариант (более правдоподобно было бы внести call_once внутрь глобального объекта, но для простоты сравнения сделал как ниже)
static std::once_flag flag;
static std::unique_ptr<TSomeExternal> ptr;
void init() {ptr = std::make_unique<TSomeExternal>(7);}
int func2() {
std::call_once(flag, init);
int x = ptr->DoCalc();
return x + 14;
}
настоящая инициализация случается только в момент первого использования (ленивая инициализация). Это может быть как плюс (позволяет не тратиться на инициализацию если данные не будут использоваться), так и минус (первые запросы/итерации будут медленными)
разные инициализаторы данных вполне могут работать одновременно из разных потоков
имхо - дорогой основной цикл (очень много инструкций до TSomeExternal::DoCalc) - это всё подготовка вызова call pthread_once, который будет выполнен каждый раз
в случае если указатель не готов, то подготовка случается под блокировкой (__cxa_guard_acquire)
конкретно в годболте не видно, но создаются слоты для guard variable for func3()::prepared и func3()::prepared (в этом смысле разницы со вторым вариантом мало)
Итого: ленивое вычисление, также возможна многопоточная инициализация, а также дешёвый success-path
Я бы назвал относительным неудобством третьего варианта, что указатель оказывается скрыт внутри функции, и надо сделать ещё доп действие чтобы использовать объект из нескольких функций. Пример такой обёртки Singleton.
NixOS: идея, до которой индустрия доросла только сейчас.
Кажется, NixOS наконец выходит из категории системы «для своих» и становится все заметнее в инженерной среде. Это закономерно: он очень точно попал в проблемы, с которыми команды массово столкнулись только в последние годы.
История началась в 2003 году, когда исследователь Элко Долстра и его коллеги в Утрехтском университете запустили проект Nix. Это исследовательский проект, который включал пакетный менеджер и собственный декларативный язык. Идея была сделать так, чтобы пакеты и зависимости собирались предсказуемо, не конфликтовали между собой и не превращали систему в хаос после очередного обновления. Чуть позже из этой логики вырос NixOS, где тот же подход применили уже ко всей операционной системе.
В этом и был главный поворот. Nix с самого начала смотрел на систему не как на набор вручную настроенных файлов и команд, а как на то, что можно описать целиком. Пакеты хранятся изолированно, разные версии могут спокойно жить рядом, а состояние машины задается через конфиг. За счет этого обновления становятся атомарными.
Это особенно интересно на фоне обычных Linux‑дистрибутивов. Там текущее состояние системы часто является результатом длинной цепочки действий: что‑то поставили, что‑то удалили, где‑то поправили конфиг, где‑то забыли. В NixOS логика другая: ты описываешь желаемое состояние, а система приводит машину именно к нему. Если новая конфигурация не взлетела, предыдущее состояние никуда не исчезает.
😏 Почему NixOS набирает популярность именно сейчас? Потому что индустрия наконец доросла до его сильных сторон. Чем больше у команды окружений, CI/CD, инфраструктуры как кода и цены ошибки, тем важнее воспроизводимость и предсказуемость. То, что раньше выглядело как нишевая экзотика, сегодня все чаще выглядит как очень здравый инженерный выбор.
Многие современные immutable‑системы по сути идут в ту же сторону, куда NixOS пошел еще много лет назад.
А если хочется не просто прочитать про Nix, а разобраться, как он работает на практике, приходите на наш открытый воркшоп.
📹 Открытый воркшоп в рамках ИнженеркаТех Плюс, 18 марта в 19:00 по МСК. Александр Сергеев из сообщества RULKC, Russian Linux Kernel Community, расскажет про Nix и функциональный подход к пакетам и сборке.
Если вы хотите получить полный контроль над окружением и наконец закрыть вопрос воспроизводимых сборок, этот воркшоп для вас. Разберем ключевые концепции Nix и наглядно покажем, чем он отличается от привычных систем управления пакетами.
🚀 Бесплатный курс для разработчиков: создаём свой язык программирования!
Приглашаем вас пройти наш курс и разобраться, как устроены языки программирования изнутри.
Изначально курс делали для прохождения внутри компании, но решили, что полезного материала так много, что хочется рассказать всему миру!
Этот курс подойдёт разработчикам, которые хотят выйти за рамки повседневной разработки и глубже понять фундаментальные принципы работы кода. Да, примеры будут на C++, но сам материал гораздо шире и будет полезен программистам с любым стеком. Независимо от того, пишете вы на C++, C#, Java или любом другом языке, понимание внутренней архитектуры языков сделает вас сильнее как инженера.
В рамках курса мы шаг за шагом разберём, как создаётся язык программирования: — что такое лексер и парсер и какую роль они играют; — как работает семантический анализ; — как происходит вычисление и обработка кода; — как все эти части объединяются в единую систему.
Вы увидите, как текст программы превращается в структуру, понятную машине, и поймёте, какие решения стоят за этим процессом.
Даже если вы не планируете создавать собственный язык программирования, курс поможет чуть глубже понять, как всё это устроено "под капотом", расширить технический кругозор и по-новому взглянуть на привычные инструменты. Это хороший способ систематизировать знания, освежить базовые концепции и просто обсудить интересные темы с коллегами.
Мы постарались сделать материал одновременно понятным и практико-ориентированным: минимум абстракции ради абстракции — максимум смысла.
Если вы хотите лучше понимать, что происходит "под капотом" программирования и прокачать инженерное мышление — этот курс для вас.
Прошу помощи. Не могу найти документацию на плату. Купил когда-то на а**-э*****сс, но к ней не было в комплекте вообще ничего. За время поисков удалось найти только два фрагмента схемы. Мб есть у кого такая....
Хорошей практикой в C++ считается размещение функций рядом с типами, для которых они предназначены. Однако, чтобы такой подход работал корректно, важно понимать механизмы поиска имён и знать, где можно размещать функции, не нарушая правил языка.
Совсем недавно мы проверяли проект OpenCV и нашли там довольно интересную ошибку. Рассмотрели её подробнее и написали новую статью специально для тех, кто хочет разобраться с механизмом поиска имён в C++, в частности с поиском имён по аргументам.
Задумывались ли вы, насколько высок современный налог на железо в разработке ПО?
У меня в руках настоящий «старичок» из 2002-го: сокет 478, матплата GA-8IR2003, Celeron 1700 МГц (по силам как Pentium III на 1 ГГц, но с поддержкой SSE2), 2 Гб ОЗУ, GeForce 4 MX и верный HDD на 40 Гб.
Я хочу написать о нем статью, но не в стиле ностальгический обзор ретро-игр такого в сети полно. Моя цель вдохнуть в него жизнь и проверить, пригоден ли этот 23-летний дедушка для современной разработки.
На борт успешно встают Windows 7 и Debian 11, что открывает доступ к актуальному софту, IDE и библиотекам. Хочется понять: реально ли на таком непотребстве поднять бэкенд на C# или собрать что-то серьезное на C++?
Запасной вариант, если основному ПК не хватит инструкций.
В запасе ПК: Athlon x4 640, 8гб ОЗУ, ssd 256.
На нем, отключая ядра и понижая частоту можно добиться симуляции ПК начиная с 2000-ого по 2010 год. Думаю этот вариант будет предпочтительнее. Но начну конечно с celeron'а.
Что планирую потестить:
C# под Linux: Запустить бэкенд и посмотреть, не «умрет» ли система.
Базы данных: Погонять PostgreSQL 9.4 (она еще дружит с 32-битными процессорами).
C++: Сравнить скорость сборки проекта с модулями и без них.
Безумный челлендж: Попробовать собрать userver. В чате разработчиков сказали "вряд ли взлетит", а мне тем более интересно проверить.
IDE: Какая версия Visual Studio оживет и можно ли в ней работать без боли.
Прошу совета у сообщества: накидайте идей! Какие бенчмарки прогнать? Какой софт или специфические проекты попробовать собрать, чтобы нащупать предел возможностей?
Будет интересно сделать вывод: пригоден ли древний ПК хоть для какой-то разработки сегодня, или «налог на железо» стал неподъемным. Жду ваши предложения!
Тихий враг или молчаливый союзник: коротко о выравнивании в C++. Часть 2
Казалось бы, тайна выравнивания раскрыта. Вы победили невидимого врага — невыровненный доступ. Память под контролем, но производительность по-прежнему шепчет: "Есть ещё нюансы". Что? Нюансы? Какие? Пришло время посмотреть, что происходит, когда структуры начинают наследовать друг друга. Здесь всё становится... интереснее. Правила игры меняются.
Итак, путь ясен: мы погружаемся в мир наследования, чтобы услышать его диалог с памятью. Давайте сразу к делу. Приготовьтесь, правила только что усложнились. В статье поговорим о выравнивании, наследовании POD-структур и множественном наследовании.
Исключения — самый коварный механизм C++. Код компилируется, тесты проходят, но в продакшне система падает из-за partially constructed object или утечки в деструкторе. Результат — часовой дебагг и нестабильность.
Основная ошибка: путаница между Basic и Strong guarantee. «Валидный» объект ≠ «корректный». Вы нарушаете инварианты, даже не подозревая об этом.
Тихий враг или молчаливый союзник: коротко о выравнивании в C++
Представьте, ваша программа — образец чистого кода, прошедший ревью и покрытый тестами. Казалось бы, всё идеально. Но производительность не такая, на какую рассчитывали. Вы проверили всё, что знали. А что, если проблема в том, о чём вы могли не знать? Всё может упираться в выравнивание данных в памяти. Для многих этот механизм так и остаётся загадкой.
Предлагаю вам вместе попробовать разобраться в такой непростой теме в этой статье.
Надоело искать парные вкладки (.h/.cpp) в VS Code? Я навайбкодил расширение, которое их магнитит.
Привет! Меня всегда немного раздражала одна мелочь в VS Code.
Открываешь Source.cpp, хочешь посмотреть заголовок, а Source.h открыт где-то в конце списка вкладок или вообще затерялся среди десятка других файлов. Приходится глазами искать его или тянуться к дереву проекта.
Стандартные методы сортировки тут не помогают, поэтому я написал Tab Magnet.
Как это работает: Вы просто кликаете на файл в Explorer-е. Tab Magnet проверяет, открыта ли его "пара" (например, .h для .c или .html для .component.ts), и если да - автоматически переносит её поближе, чтобы они стояли бок о бок.
Функционал:
Знает, что заголовки лучше держать справа, а тесты — рядом с кодом.
Поддерживает из коробки C/C++, C#, Web (JS/TS/HTML/CSS) и Angular.
Можно настроить свои правила (например, для Go тестов или специфичных структур папок).
Я подумал, что было бы интересно сделать дотошное исследование кода, который обеспечивает функционирование исключений в С++, и написать статью об этом. Разные платформы могут реализовывать исключения по-разному, поэтому показалось логичным сконцентрироваться на мире Linux.
Хотя в интернете и так много материалов по исключениям, у меня сложилось впечатление, что они либо слишком кренят в сторону технических описаний, либо описывают самостоятельную имплементацию. Я попытался сделать именно что человеческое описание подкапотной работы исключений.
Всё рассмотрение строится на конкретном примере. Где возможно, опираюсь на библиотеку libcxx от LLVM, а в остальных случаях — на libstdc++ от GCC.
Саму статью можно прочитать по этой ссылке. Если у вас появились какие-то мысли или пожелания в результате прочтения, буду очень рад увидеть вас в комментариях!
Мы иногда во внутреннем чате обмениваемся фрагментами кода с неочевидными ошибками, которые обнаруживаются с помощью PVS-Studio в каком-нибудь открытом проекте. Мол, кто быстро сообразит, что не так с кодом?
Вчера коллега поделился вот таким фрагментом кода из проекта SereneDB:
template <typename T>
struct NumericParameter : public Parameter {
using ValueType = T;
....
std::string name() const override {
if constexpr (std::is_same_v<ValueType, int16_t>) {
return "int16";
} else if constexpr (std::is_same_v<ValueType, uint16_t>) {
return "uint16";
} else if constexpr (std::is_same_v<ValueType, int32_t>) {
return "int32";
} else if constexpr (std::is_same_v<ValueType, uint32_t>) {
return "uint32";
} else if constexpr (std::is_same_v<ValueType, int64_t>) {
return "int64";
} else if constexpr (std::is_same_v<ValueType, uint64_t>) {
return "uint64";
} else if constexpr (std::is_same_v<ValueType, size_t>) {
return "size";
} else if constexpr (std::is_same_v<ValueType, double>) {
return "double";
} else {
static_assert("unsupported ValueType");
}
}
....
};
Признаюсь честно, я два раза прочитал этот фрагмент, но так и не увидел ошибку. И засчитал себе поражение. Раз так, думаю, это достойно публикации в канал, чтобы и вы могли испытать свою внимательность :)
Попробуйте найти сами
Ответ:
Анализатор PVS-Studio выдаёт предупреждение V591 Non-void function should return a value. parameters.h 222
На первый взгляд предупреждение странное и смахивает на ложное срабатывание, ведь не может быть, что функция закончила работу, не вернув значение с помощью оператора return. Если выбирается ветка else, то там static_assert, и код просто не должен скомпилироваться. Во всех остальных случаях есть return "что-то";.
Но есть нюанс!
Ещё раз посмотрите на эту строчку:
static_assert("unsupported ValueType");
static_assert используется неправильно: пропущен bool-constexpr. Вернее, строковый литерал неявно конвертируется в значение true, и static_assert никогда не прервёт компиляцию. В итоге else-ветка функции ничего не возвращает, и её поведение будет не определено для всех специализаций NumericParameter, кроме указанных ранее в цепочке if constexpr.
Слышу уже от второго человека, что язык Rust не дает нормально работать с указателями в связанных списках, деревьях и графах (в моей вселенной ЯП без этого - это как свадьба без невесты). Взял ChatGPT, задал промпт: "write a code to insert a node into a doubly linked list in rust". Оно сгенерило нечто с кучей дополнительных слов, которых не было ни в Си, ни в Паскале 40 лет назад: borrow, as_ref, and_then, upgrade, map, downgrade, Some, clone, borrow_mut. Это все реально нужно или они там совсем озверели?
Состоялся первый мажорный релиз открытого проекта для шифрования текста и файлов Stirlitz. Программа написана на языке С++ и распространяется под лицензией GPLv3. Приложение адаптировано для работы в операционных системах семейства Linux, Windows и Android. Для пользователей Arch Linux в AUR доступен сценарий сборки пакета. Для пользователей Windows доступен экспериментальный инсталлятор. Для пользователей Android доступен экспериментальный пакет в формате apk.
Основные возможности Stirlitz 1.0:
Шифрование текста и файлов для передачи через любые каналы публичной связи (мессенджеры, e‑mail сообщения и тому подобное). Шифрование осуществляется на базе публичных ключей (алгоритм Ed25519) и алгоритма шифрования AES256.
Шифрование файлов для локального хранения. Шифрование осуществляется через задание имени пользователя и пароля с использованием алгоритма AES256.
Создание шифрованных профилей для хранения ключей, используемых для обмена сообщениями через публичные каналы связи.
Создание одноразовых профилей: ключи хранятся в защищённой памяти, выделяемой с помощью библиотеки libgcrypt, и уничтожаются после выхода из профиля или закрытия программы.
Криптографические функции вынесены в отдельную библиотеку stirlitz, которая может быть собрана и использоваться полностью независимо.
Для библиотеки stirlitz доступна документация в формате html.
Звёзды разработки и практикующие инженеры разбирают горячие темы — от FAIL до GOD. Встречайте tech-шоу «АйТир Лист» от МойОфис.
В нашем шоу мы берём одну область в разработке, выбираем самые обсуждаемые технологии, практики и подходы — и раскладываем их по шкале от FAIL до GOD. Формат простой: эксперты защищают свои позиции, спорят, соглашаются и не соглашаются. 14 табличек, 14 поводов для споров и честный экспертный рейтинг без попытки всем понравиться.
Дебютный эпизод мы посвятили популярным опенсорс-решениям для фронтенда: от инструментов, которые давно пора отпускать, до стандартов индустрии.
В выпуске:
Александр Коротаев — эксперт по фронтенду и креативному кодингу
Алексей Золотых — тимлид команды веб-редакторов МойОфис
Ведущий — Эдгар Акопян
Обсуждаем инструменты, которые формируют повседневную фронтенд-разработку, и честно отвечаем на вопрос: что сегодня выглядит как GOD-tier, а что застряло на уровне MVP или FAIL.
Во втором эпизоде «АйТир Листа» — уже не инструменты, а язык. Мы устроили полноценную битву мнений вокруг фич и идиом C++: 14 табличек превращаются в 14 поводов для дебатов, где каждая возможность языка проходит через экспертную оценку.
В выпуске:
Данил Черепанов — архитектор редакторов МойОфис
Антон Полухин — эксперт-разработчик C++ техплатформы городских сервисов Яндекс
Ведущий — Эдгар Акопян
Получилось много споров, неожиданных аргументов и ситуаций, где «привычно» не значит «хорошо».
В следующих выпусках продолжим разбирать технологии без скидок на хайп и «так исторически сложилось». Предлагайте темы, а если готовы к жарким спорам – становитесь участниками нашего шоу) А как стать? Пишите в комменты с какой темой бы хотели поспорить!
