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

Subject: Re: [boost] Checking interest in std::get for PODs
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2016-06-04 16:12:08

Le 04/06/2016 à 19:51, Antony Polukhin a écrit :
> 2016-06-04 16:08 GMT+03:00 Vicente J. Botet Escriba <
> vicente.botet_at_[hidden]>:
>
>> Le 04/06/2016 à 09:52, Antony Polukhin a écrit :
>>
>>> 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 :
>>>>
>>>>
>>> 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.
>> I suspect that the optimization to get O(log(sizeof(POD))) complexity
>> could be the cause.
>> As both are possible
>>
>>      make_my_life_even_more_harder x = {1, 2, make_my_life_harder{3, 4}};
>>      make_my_life_even_more_harder y = {1, 2, 3, 4};
>>
>> If the constuctor with 4 arguments is tried before the constructor with 3,
>> what woudl happen?
>>
>> I believe that in order to find matches for UDT the algorithm should be
>> linear and start from 1.
>>
> 1 always succeeds. 2,3,4 will also succeed so there's no way to find when
> to stop.
Sorry, could you describe what is the algorithm to find out the number 
of leafs and their types?
>
>>>> Would it be interesting for Boost?
>>>>> I think so.
>>>>
>>>> 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.
>>>
>> Haskell request that the user add deriving Eq, Ord, Show in order to
>> retrieve the operations the compiler can generate. The user must opt-in.
>> Having a trait is a way to opt-in in C++. Sorry the trait should state if
>> the suer wants the default implementation for a pod.
>>
> You may always override the operators from pod_ops namespace.
> Actually enabling them by default seems to be the implementation of
> proposal with compiler generated comparisons for PODs
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4475.pdf
Yes, but you can not do that with a library  without adding to the 
global namespace.
>
> BTW, what happened with the Default Tuple-like Access proposal
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0197r0.pdf ?
> magic_get seems to provide close functionality.

After a better understanding of Structured binding It has been replaced 
by p0327r0 Product-type access 
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0327r0.pdf).

magit_get is close, but its flattened nature makes it unsuitable as an 
implementation of a product-type access.
>
>
>> What about adding also a hash function?
>>>> I'll do that soon.
>> Great. Would you will use Boost.Functional/Hash?
>
> Probably std::hash + handmade hash_combine. I'll also provide a hash_value
> function in pod_ops namespace.
> That way the hash value for structures with a single field will be equal to
> std::hash, will be interoperability with Boost and no dependencies on other
> Boost libraries.
Is someone interested in proposing to Boost something close to P0029R0 A 
Unified Proposal for Composable Hashing ?
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0029r0.html

>
>> BTW, what will be the name of the library?
>>>> That question was bothering me for a long time. I'm open to suggestions.
>>>
>>> Flatten , Leaves ?
> PRL (POD Reflecting Library), Flat, Glance?
>
PRL doesn't conveys the flatten nature. The library is reflecting the 
leaves (builtin members) of a POD.

The keywords are POD, Leaf and Reflection. Maybe PodLR - Pod Leaf 
Reflection library.

Vicente