Hi Everyone,
I am now trying to study the PFR library, and wanted to share some thoughts
and see what others think.
First, thanks Antony for writing and sharing this library. I have watched
your video on it, read the docs, and I find it amazing that you were able
to implement such reflection in C++. This is in the spirit of the good old
Boost libraries that just implemented magic.
Now, to the critique. From looking at the docs and the videos, I inferred
(perhaps incorrectly) that the library was created in this order: "We can
do type introspection for aggregates, so let's see to what extent we can
provide an interface of a reflection library." The extent is quite amazing
(e.g., I really appreciate having pfr::less<> out of the box), but to the
end user, I think, the library will still appear as incomplete. That is,
when my type is an aggregate it will work, but when I need to add a
convenience constructor it will immediately break, and I will have to
switch to another library, like Peter's Describe (
https://github.com/pdimov/describe/tree/master) With Describe, I will have
to type more, but I have a guarantee of a uniform experience both for
aggregates and for other types. And given that I have to use Describe at
some point there may be no point in also keeping PFR and forcing on myself
and my colleagues two different interfaces.
Describe is not a perfect solution either, because for aggregates I have to
declare the mapping, which is unnecessary as PFR has demonstrated.
My ideal solution would be if these two libraries (PFR and Describe) would
be merged into one, so that:
1. They provide the same interface
2. A user can easily instruct the library: "this is an aggregate: figure
out the mapping yourself".
I am sorry if it sounds arrogant: people are devoting their private time to
write and share a cool library, and all they hear back is "do more." But I
thought it would also be unfair not to give this feedback. I am also not
sure if the goals of the two libraries are compatible (e.g., Describe is
also interested in giving names of the members) . I would be curious to see
what the authors think about it.
Regards,
&rzej;
A recurring discussion in Boost.Math has been needing a cross-platform way to query the L1D cache size of a machine. I have most of a solution in a [personal repo](https://github.com/mborland/cache). It did not make sense to us to have this in Boost.Math because it would be useful outside of that scope, but we did not know where it should go. Is there an existing library where this would fit? If necessary I can roll it into a library submission that exposes the functionality of CPUID.
Matt
