Seeking endorsement for the reflection library (PFR)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Seeking endorsement for the reflection library (PFR)

Boost - Dev mailing list
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=1606


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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Seeking endorsement for the reflection library (PFR)

Boost - Dev mailing list
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)

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Seeking endorsement for the reflection library (PFR)

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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=1606
>
>
> 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
>
>


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Seeking endorsement for the reflection library (PFR)

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Seeking endorsement for the reflection library (PFR)

Boost - Dev mailing list
6 нояб. 2017 г. 0:28 пользователь "Peter Dimov via Boost" <
[hidden email]> написал:
<...>

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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Seeking endorsement for the reflection library (PFR)

Boost - Dev mailing list
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?


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Seeking endorsement for the reflection library (PFR)

Boost - Dev mailing list
6 нояб. 2017 г. 15:23 пользователь "Peter Dimov via Boost" <
[hidden email]> написал:

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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Seeking endorsement for the reflection library (PFR)

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Thanks Glen,  duly noted.

Best,
Ron

> On Nov 4, 2017, at 4:32 PM, Glen Fernandes <[hidden email]> 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)


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Seeking endorsement for the reflection library (PFR)

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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?


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Seeking endorsement for the reflection library (PFR)

Boost - Dev mailing list
9 нояб. 2017 г. 14:56 пользователь "Peter Dimov via Boost" <
[hidden email]> написал:

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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Seeking endorsement for the reflection library (PFR)

Boost - Dev mailing list
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 }.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Seeking endorsement for the reflection library (PFR)

Boost - Dev mailing list
9 нояб. 2017 г. 21:34 пользователь "Peter Dimov via Boost" <
[hidden email]> написал:

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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost