AP
А это вообще законно?
Я думал, это очередной баг стандарта...
Я думал, это очередной баг стандарта...
Мне тут подкинули ещё одну идею, как можно рефлексию делать... вот там уже совсем незаконно %)
Size: a a a
2020 October 13
AP
Молодец, Антоша!
Спасибо! Осталось внедрить в Boost.Spirit и Boost.Serialize
И получится круто и изкоробочно
И получится круто и изкоробочно
CD
Кстати, magic_get прошёл Boost review!
Я даже почти поправил все замечания https://github.com/apolukhin/magic_get/pull/51 , так что скорее всего будет в ближайшей версии Boost
P.S.: любая помошь с тестированием или подсказками по документации приветствуется http://apolukhin.github.io/magic_get/index.html
Я даже почти поправил все замечания https://github.com/apolukhin/magic_get/pull/51 , так что скорее всего будет в ближайшей версии Boost
P.S.: любая помошь с тестированием или подсказками по документации приветствуется http://apolukhin.github.io/magic_get/index.html
А PR про tuple-интерфейс агрегатов, который делает magic_get ненужным? :)
ПК
Мне тут подкинули ещё одну идею, как можно рефлексию делать... вот там уже совсем незаконно %)
ждём статью на хабре
ПК
или хотя бы доклад :)))
P
интересно можно ли это как-то эксплуатировать для рефлексии:
https://godbolt.org/z/GMK58j
https://godbolt.org/z/GMK58j
ПК
А это вообще законно?
Я думал, это очередной баг стандарта...
Я думал, это очередной баг стандарта...
Не, там всё законно в базовой имплементации
AP
А PR про tuple-интерфейс агрегатов, который делает magic_get ненужным? :)
Я конечно надеюсь, что оно попадёт в C++23, но опыт подсказывает что окажется в C++26 или C++29.
Ну и Boost в любом случае будет поддерживать старые стандарты длительное время
Ну и для Core proposal нужен опыт использования и реализация в популярных компиляторах
Ну и Boost в любом случае будет поддерживать старые стандарты длительное время
Ну и для Core proposal нужен опыт использования и реализация в популярных компиляторах
CD
Я конечно надеюсь, что оно попадёт в C++23, но опыт подсказывает что окажется в C++26 или C++29.
Ну и Boost в любом случае будет поддерживать старые стандарты длительное время
Ну и для Core proposal нужен опыт использования и реализация в популярных компиляторах
Ну и Boost в любом случае будет поддерживать старые стандарты длительное время
Ну и для Core proposal нужен опыт использования и реализация в популярных компиляторах
А magic_get не может считаться такой реализацией, поскольку он позволяет реализовать эту функциональность без компилятора?
AP
Не, там всё законно в базовой имплементации
C++17 движок совсем законный
Loophole - не очень
Базовый движок - тоже законен, но MSVC в него не умеет
Loophole - не очень
Базовый движок - тоже законен, но MSVC в него не умеет
ПК
базовый это с++14? Потому что я в С++17 в msvc юзал. И работало идеально (по сравнению с boost.fusion, который не смог в conxtexpr в msvc)
AP
А magic_get не может считаться такой реализацией, поскольку он позволяет реализовать эту функциональность без компилятора?
Подобная штука уже была с is_constant_evaluated. Его сделали в виде библиотечного решения, а приняли как ядерную часть
AP
базовый это с++14? Потому что я в С++17 в msvc юзал. И работало идеально (по сравнению с boost.fusion, который не смог в conxtexpr в msvc)
Ага, базовый c++14 движок
CD
Подобная штука уже была с is_constant_evaluated. Его сделали в виде библиотечного решения, а приняли как ядерную часть
А p1144 ([[trivially_relocatable]]) не знаете, в каком состоянии? Я все никак не соберусь с аргументацией для автора, что этот атрибут надо в user defined move ctor приписать
CD
У меня там основная примерно что правила тривиальности подозрительно напоминают правила генерации move ctor
P
А p1144 ([[trivially_relocatable]]) не знаете, в каком состоянии? Я все никак не соберусь с аргументацией для автора, что этот атрибут надо в user defined move ctor приписать
CD
спасибо
AP
А p1144 ([[trivially_relocatable]]) не знаете, в каком состоянии? Я все никак не соберусь с аргументацией для автора, что этот атрибут надо в user defined move ctor приписать
Меня больше за душу берёт предложение от Антона Жилина http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2025r1.html
CD
Меня больше за душу берёт предложение от Антона Жилина http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2025r1.html
Там базовая идея очень крутая, да. Мне кажется, что в стандарте фундаментально не хватает правил семантики операций - поправьте меня, стандарт не накладывает вообще никаких ограничений для функций, рассматриваемых компилятором как CopyCtor и MoveCtor
AP
Там базовая идея очень крутая, да. Мне кажется, что в стандарте фундаментально не хватает правил семантики операций - поправьте меня, стандарт не накладывает вообще никаких ограничений для функций, рассматриваемых компилятором как CopyCtor и MoveCtor
Есть чуть чуть на алиасинг, и то мало кто пользуется