[PFR][review] Review of PFR ends Today

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

[PFR][review] Review of PFR ends Today

Boost - Dev mailing list
The review of the PFR: Precise and Flat tuple Representation (ex
Precise and Flat Reflection, ex Magic Get, ex PODs Flat Reflection)
ends Today.
Do not hesitate to send late reviews, there's still time.

Documentation: http://apolukhin.github.io/magic_get/
Source: https://github.com/apolukhin/magic_get

I'll announce the review results soon.

Benedek
review manager

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

Re: [PFR][review] Review of PFR ends Today

Boost - Dev mailing list
On 10/7/2020 1:33 PM, Benedek Thaler via Boost wrote:
> The review of the PFR: Precise and Flat tuple Representation (ex
> Precise and Flat Reflection, ex Magic Get, ex PODs Flat Reflection)
> ends Today.
> Do not hesitate to send late reviews, there's still time.

I vote to ACCEPT the library.

My suggestions:

1) While I appreciate the links in the docs I think that an explanation
of the POD-like type with which the library can work should be added.
Merely saying "aggregate initialization", with the link to the
explanation on cppreference.com, does not really tell me precisely with
what type of structure the library can work.

2) Whatever "loophole" is should be explained fully. An end-user is
going to have little idea of whether his compiler in C++14 mode exploits
the "loophole" or not, nor will he know whether the PFR library is
figuring things out for him regarding the "loophole" unless it has a
decent practical explanation. Just pointing to a C++ paper regarding the
C++14 loophole does not seem enough to me.

3) I am not against the global operators since the doc tells me, in the
topic "Three ways of getting operators" how I can turn them off or on
depending how I want to use the library in a TU.

For the particular structure which the library can "convert" to a tuple
for further functionality in situations in which working generically
with a tuple is useful, I think the library is useful for programmers.
This is my main reason for voting to accept the library. I did not do
any extensive testing of the library, nor did I look at the internal
code, but I am satisfied the library works as advertised in its basic
functionality of struct -> tuple usage.

Although the usefulness of the library is limited, it is a tool for
working with a C-like data structs, which I am sure many C++ programmers
still use in their code. Thus my vote for acceptance.


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