-
-
Notifications
You must be signed in to change notification settings - Fork 232
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
A generic basic_claim to allow support for other libraries #71
Conversation
low laptop battery rip me
This reverts commit 5177c86.
I'll take a look at it tomorrow, but I certainly like the idea of having base64/json libraries exchangeable. |
running clang-diagnostic-*,clang-analyzer-*,-*,bugprone*,modernize*,performance*,-modernize-pass-by-value,-modernize-use-auto,-modernize-use-using
- google-readability-namespace-comments - hicpp-uppercase-literal-suffix - llvm-include-order - llvm-header-guard - readability-const-return-type - readability-else-after-return - hicpp-special-member-functions - google-readability-casting
moved to two more generic type trait validation
rr.insert(0, signature_length/2 - rr.size(), '\0'); | ||
rs.insert(0, signature_length/2 - rs.size(), '\0'); |
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.
Needs a second set of eyes
fixing typo
explaining macros/configurations
The last open question is do we official support nlohmann/json? Short of that I think I've checked all the boxes. When you get the chance, love for a code review 😃 |
|
||
const auto string = nholmann_claim(std::string("string")); | ||
const auto array = nholmann_claim(std::set<std::string>{"string", "string"}); | ||
const auto integer = nholmann_claim(159816816); |
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.
nlohmann not nholmann
I am sorry it took me this long to take a proper look at the amazing work you did here.
None of the above are a big deal/show stopper, though. EDIT: I am currently converting the code to keep all types in the traits instead of single params. |
That's absolutely all right, one thing i learnt is every one is too busy!
Totally in agreement. The only feature I If there are any other's let me know.
I was following the nlohmann/json implementation. I had been considering it myself. It was in my opening comment! |
make_void was the one that jumped my eye (which is c++17), but I honestly dont know the standards after C++14 well enough to judge what else might get replaced.
Sorry missed that :) |
I think all the possible features are int eh same block so it should not be too hard to check them. __cpp_lib_void_t might cover make_void |
Take a look, certainly can use feedback on this. Maybe it's not something that fits this project 🤷♂️
Currently I am using 3 JSON libraries, and have 3 base64 implementations so having the ability to switch out the the underlying library would be a huge asset. Others have asked for this so I went ahead with my best attempt.
Open question, should there be official nlohmann/json support?
I need to address the CMake I would like to add a few options to exclude
picojson.h
andbase.h
since it will be possible to no use those.Another point to look at, perhaps user feedback, the number of template parameters. Its very possible to have a single one
traits
which has all the type definitions required.I this gets merged it would be nice to have a pre-release and post it online for feedback 🤞 to get this over the hump.
One goal was to not break the API, there should be zero changes that affect any consumer. there's only one change in the existing test code