Re: Overcoming AST forward declaration (includes online example)
Michael Powell <[email protected]> Fri, 2 Nov 2018 18:56:50 -0400
| Newsgroups | gmane.comp.parsers.spirit.general |
|---|---|
| Message-ID | <CAMEoF_HA6Z0+CpnLk0PgpJWwUPis-YDR55+gYR26Q3ajdn6hPw@mail.gmail.com> |
On Fri, Nov 2, 2018 at 6:43 PM Larry Evans <[email protected]> wrote: > > On 11/2/18 4:33 PM, Michael Powell wrote: > > 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 > > > > I resolved a couple of obvious typos, so what remains I think are the > > forward declaration concerns: > > > > https://wandbox.org/permlink/tM6vQilplqDOL4v5 > > > Hi Michael, > > I briefly looked at the last link above and see you've noted in > the comments on lines 233 and w258 here the forward declaration > problems occur. Also, there's still the large grammar alternative > expression on line 429: Sorry for the revisions. I'm trying to help that, so that we all can focus on the question at hand best I can. > Are you sure that wouldn't cause problems because the variant attribute > for the rhs has the same type for each alternative? Why not try just > this as the sole rule in a vastly simplified grammar and see if qi > will compile that. Also, use the same idea to narrow down why the > forward declarations are causing problems. IOW, simplify your grammar > to *only* cause the forward declaration problem and then show the result > on another wandbox.org link. I'm still not following you. What do you mean? In this case, from my original code, the rule is this, synthesizing type_t() in its namespace. qi::rule<It, NS_PROTO_AST_H::type_t()> type; Which does simplify just like you said: struct type_t { std::variant<std::string, msg_type_t, enum_type_t> val; // ^^^^^^^^^ }; > type %= ( > // TODO: TBD: attempt at helping reduce the variant exhaustion a... > lexeme("double") > | lexeme("float") > | lexeme("int32") > // ... That's exactly what the parens are for, whose alternate results all reduce to std::string, correct? Whose overall result reduces to the AST variant. type %= ( lexeme["double"] | // ... Alternatives that reduce to std::string() ) | msg_type | enum_type ; > Yes, I know it's a lot more work, but it would *greatly simply the work > needed by the readers of this mailing list in their attempts to help you > and, by simplifying, you might discover the solution yourself! Much of which is simply drawn from the Protobuf v2 specification on its face. If there's a more elegant or better way to do that, I'm open to suggestions. https://developers.google.com/protocol-buffers/docs/reference/proto2-spec#fields But this is not my block right now. My block is the MessageBlock forward declaration, or, rather, how to solve that issue. > HTH. > > -Larry > > by the readers of your posts > > > > > > > _______________________________________________ > Spirit-general mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/spirit-general