-
Notifications
You must be signed in to change notification settings - Fork 142
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
Parsing glz::json_t using glz::read_json #1164
Comments
I really like this request. However, currently I do think this direct conversion would be extremely useful and not too difficult to implement. I'll definitely look into implementing this in the future. Thanks for the suggestion! |
I also had a desire for this, and had the same workaround. It would be very appreciated =D |
I'll be merging in a top-level solution to this soon: #1337. This adds support for using a Currently this uses the same costly workaround described in the comments. It serializes to JSON and then parses this. So, this merge will just simplify code that needs this translation and provide the top level API that can be optimized in the future. To make a fully optimized version of this translation would require thousands of lines of code and a massive number of tests. Because for every C++ type we would have to define the translation from So, this intermediate buffer approach is far simpler to implement, albeit it comes at a heavy translation cost. One potential optimization is to use the BEVE binary format as the intermediary translation format, rather than JSON. Because this reads/writes much faster and uses less memory. This would be invisible to the user and be a simple change. I'd appreciate any thoughts on using a binary format for the translation from |
Initial support has been merged in #1337. Currently the translation is made through JSON for the least surprise and best stability, but future optimizations will be made to make this translation much faster. I would prefer a direct translation, but this will be a significant effort. For now, this greatly simplifies code for users and provides an interface that can be optimized in the future. |
Hi, looking at the following code:
the code does not compile however I'm wondering why is that? Isn't it reasonable to allow deserializing structs from generic json using existing api and reflection? If not then why?
I managed to do the following workaround but it adds some overheads, namely writing json_t to string and then back to Widget
The text was updated successfully, but these errors were encountered: