-
-
Notifications
You must be signed in to change notification settings - Fork 6.8k
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
Make optional user-data available in from_json #864
Comments
I have thought about it, but I fail to see how the library could call I would say that such logic should be avoided in Could you precise your use case? |
My exact use case is very much like the one I shared except the root directory isn't hard-coded. In practice it will be relative to wherever the json was loaded from. For example:
I'd prefer to not save the filename at all since only the data is important. And I don't want to use global state since there could be multiple threads doing jobs that require different root directories. Another option for the user data would be caching it on the json object itself somehow? |
I would like to see a visitor-based parse API, which would be perfect for things like this. (Would also make it possible to implement a "does it parse" API as well as many other variants). Something like: MyVisitorWithExtraStuff visitor{helpfulThing1, helpfulThing2}; |
@jaredgrubb Like this? https://github.com/nlohmann/json/blob/develop/src/json.hpp#L12914-L12916
|
Hm... I didn't know that was there! I'll have to see if that will do what I was hoping. |
Can I close this issue? |
I think @jaredgrubb found a solution to his problem but mine is still the same as presented originally - wanting to pass some kind of user-data / context through to the from_json methods. It's a just a feature request though so of course you're free to close the issue if you like :) |
I think we are not able to make this extension. The whole |
I'd like to be able to supply optional user-data to json::parse which would then be retrievable in from_json. A naive implementation might look like this:
Or maybe this is already possible? Right now the only way I can see to do it requires global state or caching the data on the object and fixing it up after parsing.
The text was updated successfully, but these errors were encountered: