Подход к реализации постоянных параметров шаблонов через библиотеку

Ранее эти параметры шаблонов назывались нетиповыми параметрами шаблонов (non-type template parameters). Но с момента появления C++98 у нас всегда было три вида параметров шаблонов:

- типовые параметры (type template parameters)
- нетиповые параметры (non-type template parameters)
- шаблонные параметры-шаблоны (template template parameters)

Когда категорий всего две, можно называть их «X» и «не-X» (например, статические и нестатические методы). Но когда категорий три — это уже неудобно. А в C++26 таких категорий уже пять (добавились параметры переменных шаблонов и параметры концептов), и выходит, что почти все, кроме типовых, попадают под «нетиповые» — что нелогично. Поэтому старый термин заменили на гораздо более удачный: constant template parameter (постоянный параметр шаблона).

Этот блогпост стал продолжением моей работы с Ричардом Смитом (P2484), за которым последовала ещё одна статья по теме (P3380). И статья, и доклад основывались на блестящей идее Файсала Вали: рефлексия может предложить интересное решение задачи сериализации, ведь std::meta::info способен представлять что угодно.

На встрече в Софии все документы, касающиеся рефлексии, были включены в рабочий проект стандарта C++26, и для меня это очень воодушевляюще — видеть формулировки прямо в черновике (например, meta.reflection).

Однако моё решение по расширению поддержки постоянных параметров шаблонов в C++26 не войдёт. Как и решение проблемы non-transient constexpr allocation. Так что ограничения на типы, которые можно использовать в качестве постоянных параметров шаблонов, сохранятся ещё на один цикл.

А может… и нет?

https://brevzin.github.io/c++/2025/08/02/ctp-reflection/

#cpp #programming

🐦 Flappy Bird на Си: Вес APK < 100 Килобайт! 🚀

В сентябре 2024 года, увидев Flappy Bird на C# в дискорд-канале Raylib, я решил попробовать реализовать эту игру на Си для Android с весом APK менее 100 КБ. 🚀

Идея казалась безумной, но спортивный интерес взял верх. 💪

https://github.com/VadimBoev/FlappyBird

#cpp #programming

C умел «объектный стиль» задолго до модных споров про ООП.

В Linux-драйверах это видно особенно хорошо. Каждый драйвер фактически реализует интерфейс, просто заполняя структуру с указателями на функции.

file_operations из include/linux/fs.h - хороший пример. Ядро говорит: вот набор операций, которые может поддерживать файл, сокет или устройство. Драйвер сам решает, какие обработчики дать:

open
read
write
release
mmap
fsync
unlocked_ioctl

Если операция не нужна, поле остаётся NULL, и ядро использует поведение по умолчанию там, где это возможно.

По сути это тот же контракт между системой и реализацией, только без классов, наследования и рантаймовой магии. Есть таблица функций, есть объект, есть набор действий, которые с ним можно выполнить.

Именно поэтому C до сих пор живёт в ядрах, драйверах и системном коде. Он не навязывает модель абстракций, но даёт достаточно низкоуровневых инструментов, чтобы собрать нужную модель самому.

Просто вместо красивого слова interface у тебя struct с function pointers.

#programming #linux #c