Skip to content
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

parsing into private fields #182

Open
Jannik2099 opened this issue Jul 22, 2024 · 2 comments
Open

parsing into private fields #182

Jannik2099 opened this issue Jul 22, 2024 · 2 comments

Comments

@Jannik2099
Copy link
Contributor

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. use a proxy type, e.g.
class Myclass_impl {
public:
    char c;
};

class Myclass : private Myclass_impl {
public:
    Myclass_impl &base() { return *this; }
};

bp::rule<struct tag, Myclass_impl> rule{"rule"};
const auto rule_def = bp::char_;
BOOST_PARSER_DEFINE_RULES(rule);

void func() {
std::string str{"c"};
Myclass result;

bp::parse(str, rule, result.base());
}
  1. 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

@tzlaine
Copy link
Collaborator

tzlaine commented Sep 29, 2024

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).

@tzlaine tzlaine closed this as completed Sep 29, 2024
@tzlaine tzlaine reopened this Sep 29, 2024
@tzlaine
Copy link
Collaborator

tzlaine commented Sep 29, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants