-
Notifications
You must be signed in to change notification settings - Fork 92
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Integrating with boost::pfr? #955
Comments
If I unterstand the issue correctly, this is about conversions. From the cursory look, such feature can be a part ofBoost.PFR. PFR doesn't even have to add a physical dependency on JSON (see https://www.boost.org/doc/libs/release/libs/json/doc/html/json/conversion/avoiding_physical_dependency.html). |
Sounds really strange :) Boost.Json already have Boost.Desribe intergation, why? Doesn't it was better to make such feature a part of Describe? And then go futher and make xml, yaml, sql and anything else a part of PFR/Describe? Of course not, since they both are reflection libraries and they not obliged to be swiss knife for every reflection usecase. BTW Boost.PFR is a great candidate to be used as fallback for type for which conversion is not found. And shoud we need it as fallback, it's possible to implement only on the Boost.JSON side. |
By the same logic, Boost.JSON can't implement conversion logic for every reflection library and composite type in existence. How about this: if someone makes a JSON conversion implementation for PFR, I will integrate it as an example. |
If anyone is interested in a JSON lib that has default field reflection, check glaze. They use the same technique as boost PFR. I think boost::json needs to support reflection without specifying anything information about structs. |
The recent
pfr
update introduces a new feature allowing the retrieval of aggregated object member names.This enhancement enables the parsing and serialization of aggregate object types without the need for macros or defined functions, directly accessing the members and their names.
(For potential concerns or limitations, please refer to the caveats.)
Your thoughts on this development would be appreciated.
The text was updated successfully, but these errors were encountered: