Open pavelkryukov opened 2 years ago
Reflection TS, если я его верно понял, имеет numer_of_members
:
template <ObjectSequence T> struct get_size;
All specializations ofget_size<T>
shall meet theUnaryTypeTrait
requirements (20.10.1) with a base characteristic ofintegral_constant<size_t, N>
, whereN
is the number of elements in the object sequence.
и type_of_member
:
template <size_t I, ObjectSequence T> struct get_element;
All specializations ofget_element<I, T>
shall meet theTransformationTrait
requirements (20.10.1). The nested type namedtype
corresponds to theI
th elementObject
in T, where the indexing is zero-based.
Однако, вещей, похожих на pointer_to_member
и index_of_member
я не нашёл.
На самом деле эту тему переиграли и вроде как рефлексию собираются делать через constexpr-объекты, а не шаблоны. Я написал что и где, возможно надо будет пересмотреть идею (?) https://habr.com/ru/post/598981/
А так - можно сделать вагон крутых идей, но неясно, дойдёт ли это до SG7. У меня такое ощущение, что эту лямку Andrew Sutton тянет чуть ли не в соло.
За годы немало предложений свёрнуто с формулировкой «дождитесь интроспекции/рефлексии». Нужна какая-то проактивная позиция на этот счёт; я ничего не могу предложить лучше чем принести на стол больше мотивационных примеров.
вроде как рефлексию собираются делать через constexpr-объекты, а не шаблоны
Всё же издам глас вопиющего в пустыне: зачем сходить с накатанной лыжни?
В языке уже есть шаблоно-подобные std::is_enum
, std::is_destructible
, std::is_same
...
В языке уже есть шаблоно-подобные
std::is_enum
,std::is_destructible
,std::is_same
...
Они очень плохо подходят для рефлексии. Использование шаблона его инстанцирует, инстанс при компиляции потребляет оперативную память компилятора за счёт увеличения количества элементов во внутренних структур компилятора. Структуры с большим количеством элементов тормозят т.к. замедляют поиски и ухудшают поподания в кеш. Если рефлексия инстанцирует шаблоны и одновременно работает с контейнерами хранящими инстансы - возникают сложности с инвалидацией указателей внутри компилятора
Предложение по рефлексии https://wg21.link/P2996
У поля структуры есть три базовых представления:
offsetof
)Преобразование между тремя представлениями сделать сложно. Между первым и вторым конвертирует Type Loophole, но у этого трюка есть много ограничений, низкая скорость компиляции и т. д. Третье подключить можно, но с ещё большими ухищрениями (https://github.com/boostorg/pfr/issues/60).
При этом последнее представление и наиболее полно, и наиболее надёжно реализовано в C++ (и С). Предлагается считать его основным, и попросить компилятор объявить переменные, через которые определяются все преобразования:
В результате имплементация Boost.PFR сильно сократится:
Отсюда же порождается имплементация #468:
Не самым оптимальным образом, но порождается PR0908
index_of_member
может быть использован для метапрограммирования нестандартного расположения полей (SoA, упаковка и т. д.)