Boost

boost@lists.boost.org

October 2020

31 participants
27 discussions

[PFR] The user's perspective
by Andrzej Krzemienski 02 Oct '20

02 Oct '20

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;

5 6

Cache Size
by Matt Borland 01 Oct '20

01 Oct '20

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

3 3