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 13:51:00

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.

>
>>
>>> 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

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.

> 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.

> 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?

-- 
Best regards,
Antony Polukhin