2016-06-03 22:50 GMT+03:00 Vicente J. Botet Escriba < vicente.botet@wanadoo.fr>:
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.
Thanks! :)
I suspect that the compiler is suffering a lot, as it must try up to the size of the types isn't it?
Compiler suffers because it needs to detect the fields count. But that part was optimized and has O(log(sizeof(POD))) complexity, so in most cases the impact of magic_get is unnoticeable. 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
::value==2,""); static_assert(flat_tuple_size ::value==3,""); I have tried and it doesn't work :( http://melpon.org/wandbox/permlink/i0r0Q5xPaiwYPQMo
That's strange... I need to investigate that.
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.
Ok.
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.
Not sure that that's the right decision. However the pod_ops namespace is definitely not the right decision.
What about adding also a hash function?
I'll do that soon.
BTW, what will be the name of the library?
That question was bothering me for a long time. I'm open to suggestions. -- Best regards, Antony Polukhin