Overcoming AST forward declaration (includes online example)
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. 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
On Fri, Nov 2, 2018 at 5:16 PM Michael Powell <mwpowellhtx@gmail.com> wrote:
Hello,
Please find the example posted here:
A couple of obvious typos resolved, I think the main culprit(s) now are the forward declaration concerns: https://wandbox.org/permlink/tM6vQilplqDOL4v5
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.
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
On Fri, Nov 2, 2018 at 5:32 PM Michael Powell <mwpowellhtx@gmail.com> wrote:
On Fri, Nov 2, 2018 at 5:16 PM Michael Powell <mwpowellhtx@gmail.com> wrote:
Hello,
Please find the example posted here:
A couple of obvious typos resolved, I think the main culprit(s) now are the forward declaration concerns:
The forward declaration errors now the top most errors: https://wandbox.org/permlink/WeRqkmDR93Wqu8BI
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.
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
On 3/11/2018 11:34, Michael Powell wrote:
The forward declaration errors now the top most errors:
Fundamentally you have a cyclic recursion problem. You're trying to declare that ast_msg_body_t contains by value a variant which can contain a ast_group_t which can contain an ast_msg_body_t (and similarly for the other possible variant types). There is no possible way this could compile, as this requires the type to be infinite size. You will need to restructure things; in some cases you can rewrite things to use lists, although that's probably not appropriate here. In this case you probably need to introduce an indirection and kick something onto the heap rather than the stack. For example, you could make the body members into unique_ptrs. This would also let you make the body type use inheritance-based polymorphism rather than using a variant (which one is better depends on taste and on intended usage). (Also, while I'm not familiar with Spirit: there should be a way to make it output actual int values rather than strings, unless you need to preserve the input format.)
On Mon, Nov 5, 2018 at 12:01 AM Gavin Lambert via Boost-users <boost-users@lists.boost.org> wrote:
On 3/11/2018 11:34, Michael Powell wrote:
The forward declaration errors now the top most errors:
Fundamentally you have a cyclic recursion problem.
You're telling me. ;-)
You're trying to declare that ast_msg_body_t contains by value a variant which can contain a ast_group_t which can contain an ast_msg_body_t (and similarly for the other possible variant types).
There is no possible way this could compile, as this requires the type to be infinite size.
You will need to restructure things; in some cases you can rewrite things to use lists, although that's probably not appropriate here. In this case you probably need to introduce an indirection and kick something onto the heap rather than the stack.
For example, you could make the body members into unique_ptrs. This would also let you make the body type use inheritance-based polymorphism rather than using a variant (which one is better depends on taste and on intended usage).
Effectively, "rewriting" the AST in strategic places is what I did. I had some help, learned a couple of new tricks, and applications to a couple of old tricks, circa C++11 bits, at any rate, so far as I can determine. http://stackoverflow.com/questions/53120135/how-to-overcome-a-boost-spirit-a... And with several follow up posts.
(Also, while I'm not familiar with Spirit: there should be a way to make it output actual int values rather than strings, unless you need to preserve the input format.) _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users
Hello We have a little problem with the boost serialization. It's seems to have problem with the final keyword (at least in boost v1.55). Is there any workaround for the example oder got it fixed already in the newest boost version? class Test final { public: Test() {} Test(time_t t1) :m_t(t1) {} protected: friend class boost::serialization::access; template<class Archive> void serialize(Archive &ar,const unsigned int version ) { ar &m_t; } time_t m_t = 12; }; int main(int argc ,char**argv ){ Test t1(45); std::stringstream ofs; boost::archive::binary_oarchive oa(ofs ); oa &t1; } --> compile error: is_polymorphic.hpp(46) : error C3246: 'boost::detail::is_polymorphic_imp1<T>::d2' : cannot inherit from 'Test' as it has been declared as 'final' remarks: - the original class is a non polymorphic POD class that is declared a final. Like in th eexample! Best regards SirAnn
Am 05.11.2018 um 07:11 schrieb Dr. Sören Textor via Boost-users:
Hello We have a little problem with the boost serialization. It's seems to have problem with the final keyword (at least in boost v1.55). Is there any workaround for the example oder got it fixed already in the newest boost version? class Test final { public: Test() {} Test(time_t t1) :m_t(t1) {}
protected: friend class boost::serialization::access; template<class Archive> void serialize(Archive &ar,const unsigned int version ) { ar &m_t; }
time_t m_t = 12; };
int main(int argc ,char**argv ){ Test t1(45); std::stringstream ofs; boost::archive::binary_oarchive oa(ofs ); oa &t1; }
--> compile error: is_polymorphic.hpp(46) : error C3246: 'boost::detail::is_polymorphic_imp1<T>::d2' : cannot inherit from 'Test' as it has been declared as 'final' remarks: - the original class is a non polymorphic POD class that is declared a final. Like in th eexample! Best regards SirAnn
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users -- Dr.-Ing. Sören Textor Softwareentwicklung
phone | +49 6221 31698 225 fax | +49 6221 31698 399 email | s.textor@ditec-gmbh.de <mailto:s.textor@ditec-gmbh.de> web | http://www.ditec-gmbh.de DiTEC Dr. Siegfried Kahlich & Dierk Langer GmbH Im Breitspiel 19 | 69126 Heidelberg | Germany Handelsregister | Mannheim | HRB 341223 Dieses Dokument ist vertraulich zu behandeln. Die Weitergabe, sowie Vervielfältigung, Verwertung und Mitteilung seines Inhalts ist nur mit unserer ausdrücklichen Genehmigung gestattet. Alle Rechte vorbehalten, insbesondere für den Fall der Schutzrechtsanmeldung. This document has to be treated confidentially. Its contents are not to be passed on, duplicated, exploited or disclosed without our express permission. All rights reserved, especially the right to apply for protective rights.
participants (1)
-
Dr. Sören Textor -
Gavin Lambert -
Michael Powell