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 09:08:39

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.
>
>
>>
>>> 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.
>
>
>> What about adding also a hash function?
>>
> I'll do that soon.
Great. Would you will use Boost.Functional/Hash?
>
>
>> 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 ?

Vicente