Checking interest in std::get for PODs
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 Would it be interesting for Boost? Could it pass Boost review if it has a reinterpret_cast in it? -- Best regards, Antony Polukhin
On 3/06/2016 18:27, Antony Polukhin wrote:
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
That's pretty cool. The restriction against pointers to UDTs seems a little odd though; does that apply to arrays of UDTs as well? Do pointers to built-in types work, and if so what makes UDTs unsupported? Personally, I wouldn't use it, because I dislike relying on declared member order (which is why I'm sad that gcc/C99's named initialisation *still* hasn't made it into C++). But that's just me; I'm sure it'll be more useful to others. :)
On 6/3/2016 2:27 AM, Antony Polukhin wrote:
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
Would it be interesting for Boost? Could it pass Boost review if it has a reinterpret_cast in it?
What are the practical benefits of being able to access PODS by index as opposed to using a tuple instead ?
Hi,
What are the practical benefits of being able to access PODS by index as opposed to using a tuple instead ?
names with a proper semantic are a huge plus compared to tuples. Such a structure could be helpful in serializing simple data structures automatically. I would add that threre are existing PODs types in any application. With
Le 03/06/2016 à 14:40, Oswin Krause a écrit : this library you can have comparison, streaming, hash and any function working heterogeneous containers almost for free. There is something that I would like the library make easier: opt-in for a tuple-like access in addition to a flat_tuple-like access. Vicente
On 6/3/2016 4:01 PM, Vicente J. Botet Escriba wrote:
Hi,
What are the practical benefits of being able to access PODS by index as opposed to using a tuple instead ?
names with a proper semantic are a huge plus compared to tuples. Such a structure could be helpful in serializing simple data structures automatically. I would add that threre are existing PODs types in any application. With
Le 03/06/2016 à 14:40, Oswin Krause a écrit : this library you can have comparison, streaming, hash and any function working heterogeneous containers almost for free.
There is something that I would like the library make easier: opt-in for a tuple-like access in addition to a flat_tuple-like access.
Okay, I can understand that. For new libraries if I wanted what magic_get offered I would simply use tuples. But I do understand that there are many people still happily using PODs in their code that want what magic_get offers.
Le 03/06/2016 à 22:38, Edward Diener a écrit :
On 6/3/2016 4:01 PM, Vicente J. Botet Escriba wrote:
Hi,
What are the practical benefits of being able to access PODS by index as opposed to using a tuple instead ?
names with a proper semantic are a huge plus compared to tuples. Such a structure could be helpful in serializing simple data structures automatically. I would add that threre are existing PODs types in any application. With
Le 03/06/2016 à 14:40, Oswin Krause a écrit : this library you can have comparison, streaming, hash and any function working heterogeneous containers almost for free.
There is something that I would like the library make easier: opt-in for a tuple-like access in addition to a flat_tuple-like access.
Okay, I can understand that. For new libraries if I wanted what magic_get offered I would simply use tuples. But I do understand that there are many people still happily using PODs in their code that want what magic_get offers. If you need to interact with C-libraries you can not choose :)
Vicente
On 6/4/2016 8:41 AM, Vicente J. Botet Escriba wrote:
Le 03/06/2016 à 22:38, Edward Diener a écrit :
On 6/3/2016 4:01 PM, Vicente J. Botet Escriba wrote:
Hi,
What are the practical benefits of being able to access PODS by index as opposed to using a tuple instead ?
names with a proper semantic are a huge plus compared to tuples. Such a structure could be helpful in serializing simple data structures automatically. I would add that threre are existing PODs types in any application. With
Le 03/06/2016 à 14:40, Oswin Krause a écrit : this library you can have comparison, streaming, hash and any function working heterogeneous containers almost for free.
There is something that I would like the library make easier: opt-in for a tuple-like access in addition to a flat_tuple-like access.
Okay, I can understand that. For new libraries if I wanted what magic_get offered I would simply use tuples. But I do understand that there are many people still happily using PODs in their code that want what magic_get offers. If you need to interact with C-libraries you can not choose :)
What, C doesn't have tuples yet ? <g> I program in C++. Personally I have left C far behind. Bjarne and Linus not withstanding, I think C++ as a language should be less backward accomodating to C and move forward on its own more. I do understand that PODs are still attractive as data types. Therefore I think that magic_get would be a nice addition to Boost.
On 06/03/2016 01:27 AM, Antony Polukhin wrote:
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
Would it be interesting for Boost? Could it pass Boost review if it has a reinterpret_cast in it?
Hi Antony, I've no immediate use for it yet; however, I would like to understand the implementation. I tried looking over the code here: https://github.com/apolukhin/magic_get/blob/master/magic_get.hpp However, it still was not obvious to me how the code works. Could you please maybe provide some explanation of that? TIA. -regards, Larry
On 06/03/2016 01:27 AM, Antony Polukhin wrote:
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
Would it be interesting for Boost? Could it pass Boost review if it has a reinterpret_cast in it?
I think library like that will be quite useful, especially for serialization purposes. Maybe it could be somehow integrated with boost.serialization so it would be much easier to serialize PODs in it? I have actually been using similar, however, less sophisticated approach, when I was implementing a serialization extension for proposed boost.di, so that one could serialize whole application tree without any macros or changes, which is always a good thing, I guess. You can check it out here. http://boost-experimental.github.io/di/extensions/index.html#serialize My approach is not as complete as yours as it's just a DI extensions/showcase. However, I find it quite useufl, so maybe my silly solution could be potenially replaced by the proposed library. Cheers, Kris On Fri, Jun 3, 2016 at 2:53 PM, Larry Evans <cppljevans@suddenlink.net> wrote:
On 06/03/2016 01:27 AM, Antony Polukhin wrote:
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
Would it be interesting for Boost? Could it pass Boost review if it has a reinterpret_cast in it?
Hi Antony,
I've no immediate use for it yet; however, I would like to understand the implementation. I tried looking over the code here:
https://github.com/apolukhin/magic_get/blob/master/magic_get.hpp
However, it still was not obvious to me how the code works. Could you please maybe provide some explanation of that?
TIA.
-regards, Larry
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Am 03.06.2016 um 08:27 schrieb Antony Polukhin:
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
Would it be interesting for Boost? Could it pass Boost review if it has a reinterpret_cast in it?
I'd love to see that. Would you actually be able to convert a POD into a deduced tuple?
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. I suspect that the compiler is suffering a lot, as it must try up to the size of the types isn't it? 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 I suspect that this is related to the way the constructions with k parameters are tried. Could you tell us more?
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. 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. Can a Boost library add functions in the global namespace subject to SFINAE on some specific condition? What about adding also a hash function? BTW, what will be the name of the library? Best, Vicente
Le 03/06/2016 à 21:50, Vicente J. Botet Escriba a écrit :
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
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.
Can a Boost library add functions in the global namespace subject to SFINAE on some specific condition? BTW, what about having those operator on a tuple_ops namespace appliable to tuple-like access?
Vicente
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 :
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
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 :
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
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<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
Le 04/06/2016 à 19:51, Antony Polukhin a écrit :
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<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
participants (8)
-
Antony Polukhin -
Edward Diener -
Gavin Lambert -
Klemens Morgenstern -
Krzysztof Jusiak -
Larry Evans -
Oswin Krause -
Vicente J. Botet Escriba