-
-
Notifications
You must be signed in to change notification settings - Fork 6.7k
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
templated input adapters #1950
templated input adapters #1950
Conversation
The 4 code violations are all from effectively unaltered code. I could fix them, but I don't think this PR is the place to do that. |
This pull request introduces 2 alerts when merging 2e2cf02 into 973c52d - view on LGTM.com new alerts:
|
The 2 remaining Travis failures seem like CI setup issues unrelated to my change (it fails to build CMake somehow). This should be ready for review at this point. |
Is there anything else preventing this from going through? Not that I'm any rush to have that go through, but I can't guarantee that I'll have the availability to address further changes indefinitely. |
I’ll check soon. Sorry for the delay. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some minor comments.
I think it would be also a good idea to provide an example for a user-define input adapter. What do you think? |
So I've been giving this is bit of thought before diving in. It's certainly possible to write a custom input adapter, but it's far from the ideal interface here. The "correct" answer would be to support input iterators in general, and have the user express their inputs as a pair of custom input iterators of I'm kinda tempted to just add that support in instead of creating an example that would be deprecated as soon as that went. Thoughts? |
Yes, please offer support for user defined input_adapters. There are other (now closed as stale) issues for custom input_adapter and custom output_adapter. These would be very very useful for a bunch of purposes -- custom containers, custom filesystem interfaces (e.g. through zlib), filters to do things like stripping non-standard comments, and so forth. Pretty please with sugar on top? |
@FrancoisChabot sorry for not checking back on this earlier! I really like the changes, but do you think merging now makes sense, when the request for user-defined input adapters is still open? |
Yes, I think custom input adapters are a separate issue. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me.
🔖 Release itemThis issue/PR will be part of the next release of the library. This template helps preparing the release notes. Type
Description
|
@FrancoisChabot Thanks a lot!!! |
This addresses #1457.
This change templates the lexer and parser on the input adapter. This accelerates parsing by:
Notes:
input_adapter
a function with a bunch of overloads). This PR introduces enough disruption as it is.input_adapter()
call to return astd::shared_ptr<input_adapter_protocol>
would allow someone to force the current behavior, but I'm sure anyone would actually want that.Preliminary benchmark results (the benchmark code was completely unaltered):
Before:
After:
Pull request checklist
Read the Contribution Guidelines for detailed information.
include/nlohmann
directory, runmake amalgamate
to create the single-header filesingle_include/nlohmann/json.hpp
. The whole process is described here.