-
Notifications
You must be signed in to change notification settings - Fork 67
#231 Added pfr extension #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
Conversation
|
Looks interesting 🙂 I have to accustomate myself with pfr first before reviewing here. |
|
I haven't inspected... Why are the checks failing? |
Yes! There is some checks failing.. |
|
@djowel i'm done. Appveyor's checks was fixed. Travis was fixed too, but now we cant verify this)) |
|
I'll look and study tomorrow |
|
Hello everyone! This PR will be extended in the future. I suppose, we need an alternative way to tell fusion that structure must be serialized by pfr, it's way without 'adapt' macro. |
|
All checks have failed? What's up with that? Still having 'cl' is not recognized as an internal or external command... it seems. Hrmmm... |
Addition to my previous comment.. Consider this simple fusion-able structure: I suggest giving the user of the library the ability to choose from two ways: Will print "100 200 ", because 2. boost::fusion::pfr_fields approach Will print "100 200 300 " because For a structure that is not fusion-able, it makes no difference which way to choose, because @djowel what do you say about this? |
|
Duplicate of the #243 |
So, here is my implementation of pfr extension for boost fusion library. This extension may be useful for some boost spirit users.
I am ready to answer any question you may have to facilitate the consideration of this PR. Thank you for attention.