Seeking endorsement for the reflection library (PFR)
Hello, PFR is a C++14 library that provides tuple-like methods for aggregate initializables. Library has a set of predefined operators and useful functions for everyday use. Works with user-defined types without any macro or boilerplate code. Library: https://github.com/apolukhin/magic_get Docs: http://apolukhin.github.io/magic_get/ Boost Library Incubator: http://blincubator.com/bi_library/pfr-pod-flat-reflection/?gform_post_id=160... Seeking for some endorsement, as per http://www.boost.org/development/submissions.html Library changes since last mail: * Now works on latest MSVC in C++17 mode * C++14 limitations in reflection were significantly relaxed * Removed UB (no more reinterpret casting of unrelated types!) * Thaler Benedek was approved as a review manager for the library. Boost libraries that may benefit from PFR: * Convert - for out-of-the-box conversions of user types * Hana - for using user types instead of tuples * Intrusive - for reusing unused bits in user provided types * Serialization - for out-of-the-box serialization of user types * Spirit - for putting rule results into user provided types without Phoenix or Fusion macro * Test - for outputting content of user provided types * TypeTraits - for traits like has_unique_object_representations in C++14 -- Best regards, Antony Polukhin
On Sat, Nov 4, 2017 at 4:24 PM, Antony Polukhin wrote:
PFR is a C++14 library that provides tuple-like methods for aggregate initializables. Library has a set of predefined operators and useful functions for everyday use. Works with user-defined types without any macro or boilerplate code.
Library: https://github.com/apolukhin/magic_get Docs: http://apolukhin.github.io/magic_get/
Seeking for some endorsement, as per http://www.boost.org/development/submissions.html
I endorse PFR. Glen (+Ron to CC)
Thanks Glen, duly noted. Best, Ron
On Nov 4, 2017, at 4:32 PM, Glen Fernandes <glen.fernandes@gmail.com> wrote:
On Sat, Nov 4, 2017 at 4:24 PM, Antony Polukhin wrote:
PFR is a C++14 library that provides tuple-like methods for aggregate initializables. Library has a set of predefined operators and useful functions for everyday use. Works with user-defined types without any macro or boilerplate code.
Library: https://github.com/apolukhin/magic_get Docs: http://apolukhin.github.io/magic_get/
Seeking for some endorsement, as per http://www.boost.org/development/submissions.html
I endorse PFR.
Glen
(+Ron to CC)
I endorse PFR too! Library sounds extremely useful. Mike... Am 04.11.2017 um 21:24 schrieb Antony Polukhin via Boost:
Hello,
PFR is a C++14 library that provides tuple-like methods for aggregate initializables. Library has a set of predefined operators and useful functions for everyday use. Works with user-defined types without any macro or boilerplate code.
Library: https://github.com/apolukhin/magic_get Docs: http://apolukhin.github.io/magic_get/ Boost Library Incubator: http://blincubator.com/bi_library/pfr-pod-flat-reflection/?gform_post_id=160...
Seeking for some endorsement, as per http://www.boost.org/development/submissions.html
Library changes since last mail: * Now works on latest MSVC in C++17 mode * C++14 limitations in reflection were significantly relaxed * Removed UB (no more reinterpret casting of unrelated types!) * Thaler Benedek was approved as a review manager for the library.
Boost libraries that may benefit from PFR: * Convert - for out-of-the-box conversions of user types * Hana - for using user types instead of tuples * Intrusive - for reusing unused bits in user provided types * Serialization - for out-of-the-box serialization of user types * Spirit - for putting rule results into user provided types without Phoenix or Fusion macro * Test - for outputting content of user provided types * TypeTraits - for traits like has_unique_object_representations in C++14
Antony Polukhin wrote:
Hello,
PFR is a C++14 library that provides tuple-like methods for aggregate initializables. Library has a set of predefined operators and useful functions for everyday use. Works with user-defined types without any macro or boilerplate code.
Library: https://github.com/apolukhin/magic_get Docs: http://apolukhin.github.io/magic_get/
I enjoyed your talk (https://www.youtube.com/watch?v=abdeAew3gmQ). Quite inspirational. One thing that immediately came to mind was that you can avoid using macros for the type registration by putting all the types into an mp_list and then use mp_at/mp_find to go from index to type and vice versa. Flat/precise strikes me as odd though. Do we have to have both? Precise seems to be what I'd always want.
6 нояб. 2017 г. 0:28 пользователь "Peter Dimov via Boost" < boost@lists.boost.org> написал: <...> I enjoyed your talk (https://www.youtube.com/watch?v=abdeAew3gmQ). Quite inspirational. Thanks! One thing that immediately came to mind was that you can avoid using macros for the type registration by putting all the types into an mp_list and then use mp_at/mp_find to go from index to type and vice versa. Yes, but the macro idea came to me first. MPL is slow and adds dependency to Boost library, so I'm avoiding it right now. Flat/precise strikes me as odd though. Do we have to have both? Precise seems to be what I'd always want. Flat reflection is left there mostly for users that wish to use library on a C++14 compiler and do not wish to exploit the core language defect. But you are right, most of the users will prefer precise reflection.
Antony Polukhin wrote:
Yes, but the macro idea came to me first. MPL is slow and adds dependency to Boost library, so I'm avoiding it right now.
I was thinking about mp11, not MPL. :-)
Flat/precise strikes me as odd though. Do we have to have both? Precise seems to be what I'd always want.
Flat reflection is left there mostly for users that wish to use library on a C++14 compiler and do not wish to exploit the core language defect. But you are right, most of the users will prefer precise reflection.
From your talk I was left with the impression that everything needed for precision already worked on C++14? The only problem is that you have to reinterpret_cast to a layout-compatible type instead of using structured bindings.
Initially I though that flat is what you get because you can initialize aggregates with the total "flat" element count due to brace elision: struct X1 { int a, b; }; struct X2 { double c, d; }; struct X3 { X1 x1; X2 x2; }; auto x3 = X3{ 1, 2, 3, 4 }; but then I tried it with ubiq{} and it doesn't work. So this is not a problem and the fields can be counted "precisely". So what's the issue?
6 нояб. 2017 г. 15:23 пользователь "Peter Dimov via Boost" < boost@lists.boost.org> написал: Antony Polukhin wrote:
Yes, but the macro idea came to me first. MPL is slow and adds dependency to Boost library, so I'm avoiding it right now.
I was thinking about mp11, not MPL. :-)
Flat/precise strikes me as odd though. Do we have to have both? Precise > seems to be what I'd always want.
Flat reflection is left there mostly for users that wish to use library on a C++14 compiler and do not wish to exploit the core language defect. But you are right, most of the users will prefer precise reflection.
From your talk I was left with the impression that everything needed for precision already worked on C++14? The only problem is that you have to reinterpret_cast to a layout-compatible type instead of using structured bindings.
That was fixed. No more UB in that place. The trick is to get offsets and then use pointer arithmetic to get correct pointer to the type directly. Initially I though that flat is what you get because you can initialize aggregates with the total "flat" element count due to brace elision: struct X1 { int a, b; }; struct X2 { double c, d; }; struct X3 { X1 x1; X2 x2; }; auto x3 = X3{ 1, 2, 3, 4 }; but then I tried it with ubiq{} and it doesn't work. So this is not a problem and the fields can be counted "precisely". So what's the issue? You can not extract the X1 and X2 types from ubiq{} without registering them in the map first or exploiting core language issue. However you can register all the builtin types in the map, flatten the X3 till builtin types and extract that knowledge.
Antony Polukhin wrote:
You can not extract the X1 and X2 types from ubiq{} without registering them in the map first or exploiting core language issue. However you can register all the builtin types in the map, flatten the X3 till builtin types and extract that knowledge.
You got me wondering here. Is it not possible to pass an array of size_t to the size_t* parameter, instead of a single size_t, and then encode the layout of X1 in it?
9 нояб. 2017 г. 14:56 пользователь "Peter Dimov via Boost" < boost@lists.boost.org> написал: Antony Polukhin wrote: You can not extract the X1 and X2 types from ubiq{} without registering
them in the map first or exploiting core language issue. However you can register all the builtin types in the map, flatten the X3 till builtin types and extract that knowledge.
You got me wondering here. Is it not possible to pass an array of size_t to the size_t* parameter, instead of a single size_t, and then encode the layout of X1 in it? Yes, that is what the flat reflection does. But during this operation the X1 type flattens/decays to the the basic types. You can not get X1 from a record of {int, int}. And you can not remember X1 because it is not registered in the map.
Antony Polukhin wrote:
You got me wondering here. Is it not possible to pass an array of size_t to the size_t* parameter, instead of a single size_t, and then encode the layout of X1 in it?
Yes, that is what the flat reflection does. But during this operation the X1 type flattens/decays to the the basic types. You can not get X1 from a record of {int, int}.
Ah right. You can only get an anonymous tuple_like<int, int> type, not X1. But isn't this still better than flattening? You could print it as { { 1, 2 }, { 3, 4} }, instead of { 1, 2, 3, 4 }.
9 нояб. 2017 г. 21:34 пользователь "Peter Dimov via Boost" < boost@lists.boost.org> написал: Antony Polukhin wrote:
You got me wondering here. Is it not possible to pass an array of size_t to the size_t* parameter, instead of a single size_t, and then encode > the layout of X1 in it?
Yes, that is what the flat reflection does. But during this operation the X1 type flattens/decays to the the basic types. You can not get X1 from a record of {int, int}.
Ah right. You can only get an anonymous tuple_like<int, int> type, not X1. But isn't this still better than flattening? You could print it as { { 1, 2 }, { 3, 4} }, instead of { 1, 2, 3, 4 }. That's one of the options. Some time ago I thought that is it less usefull than returning flattened type. Nowadays there's a precise reflection that does a lot of things much better, so I see no big need in improving flat reflection.
participants (5)
-
Antony Polukhin -
Glen Fernandes -
Mike Gresens -
Peter Dimov -
Ronald Garcia