You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Just don't use private members, which means your parser is no longer a parser, just a validator.
1. makes public headers unreadable as users would have to look into implementation headers to see the actual class body, while 2. violates the parse, don't validate principle and thus allows for invalidly constructed objects that would never be returned from a successful parse.
Are there any plans to remedy this, e.g. via a Boost.Parser helper class that the user class could befriend, or via a specialization that grants access to the private members (Boost.Describe comes to mind) ?
Or am I just missing a workaround that everyone has been using for the past decade
The text was updated successfully, but these errors were encountered:
Uh, no, there are no plans for this. IMO, no library should be writing into your private data members without the purpose of the library being very closely tied to the domain of your type (stl_interfaces::iterator_interface used as an adaptor, for instance).
Actually, now that I think about it a bit, this might not be a bad idea once we get P2996 in the standard (hopefully, that's C++26). At that point, it might make sense to have an access-granting type that you can befriend, and then just use the reflection machinery. I'll leave this ticket open to investigate that.
Currently my biggest gripe with Spirit.X3 is that you can't parse into a class with private fields. This leaves you with two options:
1.
makes public headers unreadable as users would have to look into implementation headers to see the actual class body, while2.
violates the parse, don't validate principle and thus allows for invalidly constructed objects that would never be returned from a successful parse.Are there any plans to remedy this, e.g. via a Boost.Parser helper class that the user class could befriend, or via a specialization that grants access to the private members (Boost.Describe comes to mind) ?
Or am I just missing a workaround that everyone has been using for the past decade
The text was updated successfully, but these errors were encountered: