Шаблоны против статической рефлексии в C++: пять операций, две реализации и дедупликация, которая не стоит памяти

[SilverTrouse]

Не совсем понял, это перевод какой-то статьи ( не увидел ссылки). Просто gcc-16 уже имеет в себе рефлексию.

А замеры классные. От такого очень много выйгрыша

[electric_warrior]

Это не перевод, это оригинальная статья и библиотека, созданная автором

[DenisT]

Это личный проект, не перевод.

Спасибо за замечание, я действительно упустил, что GCC 16 уже поддерживает рефлексию. Добавил UPD с замерами и пуш в проект с поддержкой GCC. Эти замеры, конечно, подрывают посыл статьи, но, надеюсь, добавляют ценности))

[electric_warrior]

Суровая разница между между clang-p2996 и gcc16

Есть шанс что в одном из них просто баг и результирующий type_list неверен или пуст?

[DenisT]

Это особенность реализации consteval интерпретатора GCC (часть рефлексии связана с consteval), который выделяет память пропорционально объёму вычислений и не освобождает выделенную память до конца сборки, Clang работает по-другому: потребляет константную память на consteval вычислениях. Видимо, архитектурные особенности.

Перепроверил: замер был действительно на рефлексии, а не провалился на шаблоны, тесты тоже все проходят

[SilverTrouse]

ну gcc будем честны сам по себе медленнее работает. В среднем время компиляции у gcc выше чему у clang. На идвидуальных замерах, если проект на модулях, то он в 2-3 раза медленнее чем clang, а если без модулей - в 20 процентов медлннее в среднем

[Amomum]

Жаль, что нейрослоп, тема-то интересная, но зачем же каждое второе слово делать жирным, почему в нейротекстах это так популярно, неужели только меня это отвлекает так сильно, что текст читать не хочется?

[Pubert]

Жаль, что Вы испугались жирного текста (где, кстати?) и не прочитали статью.

Давайте я, как человек, прочитавший всё от начала до конца, расскажу, почему Вы ошибаетесь.

Почему это не нейрослоп? Это отличный вопрос! Здесь есть:

1. Реальные замеры быстродействия во всевозможных кейсах

2. Куски кода с подробными объяснениями

3. Советы, как не наступить на те же грабли, что автор

4. Автор отвечает на комментарии и добавляет UPD в статью

Призываю всех комментаторов, делающих подобные поспешные выводы, сначала прочитать статью, а потом уже писать, что статья - нейрослоп. Либо не писать комментарий вовсе, дабы никого не вводить в заблуждение

[ReadOnlySadUser]

Гораздо интереснее, что там будет в ошибках компиляции и как это будет дружить с IDE. Ну и немножко интересно, сколько этажей мусора будет в отладчике.

В целом, если сейчас даже большой шаблон падает - всё, конечно плохо, но любая ИИ-шка за 5 секунд найдет проблемный параметр, да и глазами это возможно, просто дольше

[DenisT]

Честно - мусора будет много, итоговые типы получаются длинными и не читаемыми, но во многих местах, где это имело смысл, подложены static_assert, например, в метод get. Если вы пытаетесь взять из коллекции типов то, что туда не клали - сообщение об ошибке явно об этом скажет и стек трейс вызовов будет вполне собираем.

Намного сложнее разобраться, почему в коллекции нет того типа, который, как вы ожидаете, должен там быть. Такое возможно, если в проекте выстроена сложная цепочка маппингов (активно используете метод transform). Тогда отлаживать нужно шаблоны, которые выводятся на этапе компиляции, а не рантайм с привычным стектрейсом. К счастью clangd-based IDE хорошо раскручивают шаблоны и автодополнение по ним нормально работает. Например, набрав engine.get<FrameBuffer>(). IDE корректно подсветит доступное поле width . Также хорошо помогают юнит-тесты.

Все это плата за перенос рантайм ошибок на этап компиляции. Например, если DI не подтянул какой-то сервис в рантайме, то вы узнаете об этом только собрав приложение и запустив его, потом просидите с дебаггером разбираясь, почему DI не отработал как нужно. С предложенным подходом в статье ошибка проявится во время сборки и разбор проблем с кодом просто перейдет в другую плоскость.

[ReadOnlySadUser]

Да в целом-то понятно, что платить приходится (правда Haskell тихонько хихикает над нами), но просто интересно насколько много. Например, как быстро начнет тупить IDE, сколько памяти будет жрать и как часто глючить.

Насколько вообще будет поддерживаемый этот код, ведь когнитивная нагрузка, чтобы понять что тут имел ввиду автор рефлексии игромно. Принесёт ли это баги в dynamic_cast)

Ладно, надо тестировать, спасибо за статью