Re: Overcoming AST forward declaration (includes online example)
Michael Powell <[email protected]> Fri, 2 Nov 2018 22:45:47 -0400
| Newsgroups | gmane.comp.parsers.spirit.general |
|---|---|
| Message-ID | <CAMEoF_GCZe6C_vvKMCV3cmLJHnEj0rjFSDH9SQvMnw+HMb2LDg@mail.gmail.com> |
On Fri, Nov 2, 2018 at 10:18 AM Michael Powell <[email protected]> wrote: > > Hello, > > Please find the example posted here: > > http://wandbox.org/permlink/NI2Luvrw1HF7lF1E > > The couple of concerns I have in question at the moment are: > > * How to best handle variants throughout the grammar. Can I use > std::variant? Do I need to use boost::variant? Are there additional > Spirit features that make this doable? > > * Embedded in that question is what to do with "nil" or "empty > statements" which occurs throughout the grammar at times. I wondered > if "empty statement" could synthesize "nothing", literally, not > contribute to a variant alternative, for instance. Other AST examples > seemed to inject a "struct nil {}" pattern, so I figured maybe this > was the better approach? > > * The real kerfuffle for me at the moment is the AST forward > declaration. From what I gather in the protocol, this is an absolute > must have. It most occur before Group, and is also used by Message. Perhaps if I ask a different question. Is Spirit Qi able to synthesize and work with POINTERS (preferably the SMART ones if possible) instead of declaring the members as with my initial draft; and adapted member pointers. Based on responses to: https://stackoverflow.com/questions/1885471/forward-declaration-of-class-doesnt-seem-to-work-in-c#answer-1886701 I'm not positive of another viable workaround to the forward declaration issue. > Thoughts? Suggestions? > > And, please, before you suggest there are "proto compilers" already > available: yes, I know, I've been down that road. I am not looking to > parse the proto itself, per se, but rather do some code generation for > target language artifacts other than the proto itself. > > Toward which end, I am also investigating a protoc compiler plugin > approach. But I figured, I'd pursue this as a viable path to solving > the problem as well, notwithstanding the above challenges. > > Thanks in advance! > > Cheers, > > Michael Powell