2016-06-04 16:08 GMT+03:00 Vicente J. Botet Escriba < vicente.botet@wanadoo.fr>:
Le 04/06/2016 à 09:52, Antony Polukhin a écrit :
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 :
size of the types isn't it?
Compiler suffers because it needs to detect the fields count. But that
I suspect that the compiler is suffering a lot, as it must try up to the 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.
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