Re: [boost] Checking interest in std::get for PODs

Subject: Re: [boost] Checking interest in std::get for PODs
From: Antony Polukhin (antoshkka_at_[hidden])
Date: 2016-06-04 03:52:13

2016-06-03 22:50 GMT+03:00 Vicente J. Botet Escriba <
vicente.botet_at_[hidden]>:

> 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<make_my_life_harder>::value==2,"");
> static_assert(flat_tuple_size<make_my_life_even_more_harder>::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