Le 03/06/2016 à 08:27, Antony Polukhin a écrit :
Hi,
There's a C++14 library that is able to do basic reflections for PODs without any macro magic or markup: https://github.com/apolukhin/magic_get Hi Anthony, this is really magic ;-)
Using
T tmp{ ubiq_val{types + get<I>(offsets)}... };
as a mechanism to detect that T is constructible from N *ubiquitous*
values convertible to its parts and store at the same time the size is
simply brilliant.
I suspect that the compiler is suffering a lot, as it must try up to the
size of the types isn't it?
I understand that it would be quite hard for the user to associate a
unique number to a type, but it is just for curiosity, could the type
registration be extended by the user so that we can avoid flattening?
struct make_my_life_harder { int a0; short a1; };
struct make_my_life_even_more_harder { unsigned int b0; unsigned short
b1; make_my_life_harder cr;};
namespace detail {
namespace typeid_conversions {
BOOST_MAGIC_GET_REGISTER_TYPE(make_my_life_harder , 24)
}
}
static_assert(flat_tuple_size
Would it be interesting for Boost?
I think so.
Could it pass Boost review if it has a reinterpret_cast in it?
Is this related to UB? I believe that the documentation should then mention the trick so that the user is aware of it. It is worth signaling that this is not an implementation of std::get for PODs as the fields are flattened. I like the pod_ops namespace with comparison and streaming. I believe that it will be worth adding them on the global namespace subject to some specific trait xxx::pod_equality_comparable, xxx::pod_less_than_comparable, xxx::pod_streamable. The user would need just to specialize these traits to enable the operators. Can a Boost library add functions in the global namespace subject to SFINAE on some specific condition? What about adding also a hash function? BTW, what will be the name of the library? Best, Vicente