boost-spirit-qi

Dynamically combine Boost.Spirit.Qi rules at runtime (arbitrary number of alternatives)

ⅰ亾dé卋堺 提交于 2019-12-03 05:09:07
问题 I was wondering whether there is a way in Boost.Spirit.Qi to dynamically combine an arbitrary number of rules at runtime. The inner workings of Boost.Spirit are still a bit of a mystery to me, but since rules are implemented as objects it seems feasible. My motivation is to make certain parts of my grammar easily extendable. Consider the following contrived example: namespace qi = boost::spirit::qi; namespace px = boost::phoenix; typedef std::string::const_iterator iterator_t; template

Is it possible to re-use boost::spirit::qi grammar in another grammar definition?

大城市里の小女人 提交于 2019-12-03 04:38:18
Is it possible to reuse boost::spirit:qi grammar in another grammar (as a rule for example)? For example if I define a grammar to parse line of text into a structure holding street address. template< typename iter > struct address_grammar : qi::grammar< iter, address() > { ... qi::rule< iter, std::string() > street_name; qi::rule< iter, std::string() > street_number; qi::rule< iter, address() > address_; } I might want to reuse that grammar in two other grammars, for example one might be for parsing of a vector of addresses stored in a file. Another re-use might be in more complex structure

Boost.Spirit.Qi: How to return attributes with Nabialek trick

隐身守侯 提交于 2019-12-03 02:30:25
Following several tutorials (e.g. http://boost-spirit.com/home/articles/qi-example/nabialek-trick/ ) I want to use the Nabialek trick to have a dynamic parser. Parsing already works fine, but I don't get the attributes transported. Explanations like https://stackoverflow.com/a/9109972/2524462 suggest, that attributes should be possible but not arguments. This is just a small example parsing a string and a number into a struct. It is just for showcasing my problem; this method should be used in a larger system later on, where the dynamic parser is really needed. Question: How do I transport

Dynamically combine Boost.Spirit.Qi rules at runtime (arbitrary number of alternatives)

一世执手 提交于 2019-12-02 18:26:38
I was wondering whether there is a way in Boost.Spirit.Qi to dynamically combine an arbitrary number of rules at runtime. The inner workings of Boost.Spirit are still a bit of a mystery to me, but since rules are implemented as objects it seems feasible. My motivation is to make certain parts of my grammar easily extendable. Consider the following contrived example: namespace qi = boost::spirit::qi; namespace px = boost::phoenix; typedef std::string::const_iterator iterator_t; template<typename Expr> inline bool parse_full(const std::string& input, const Expr& expr) { iterator_t first(input

boost spirit on_error not triggered

笑着哭i 提交于 2019-12-02 10:51:33
问题 ^ No it is not. This was part of the problem, but if review the code as is right now, it already does what the pointed out question/answer shows ... and the errors are still not triggered. I have this boost spirit parser for string literal. It works. Now I would like to start handle errors when it fail. I copied the on_error handle 1-1 from the mini xml example and it compiles, but it is never triggered (no errors are outputted). This is the parser: #define BOOST_SPIRIT_USE_PHOENIX_V3 #define

parsing into std::vector<string> with Spirit Qi, getting segfaults or assert failures

拟墨画扇 提交于 2019-12-02 05:45:35
I am using Spirit Qi as my parser, to parse mathematical expressions into an expression tree. I keep track of such things as the types of the symbols which are encountered as I parse, and which must be declared in the text I am parsing. Namely, I am parsing Bertini input files , a simple-ish example of which is here , a complicated example is here , and for completeness purposes, as below: %input: our first input file variable_group x,y; function f,g; f = x^2 - 1; g = y^2 - 4; END; The grammar I have been working on will ideally find declaration statements, and then parse the following comma

Boost spirit using local variables

无人久伴 提交于 2019-12-02 04:44:23
问题 I would like to define a rule based on a previously parsed value, i. e. the input string has the following structure: D <double number> or I <integer number> . I keep in a local boolean variable whether the first read character is D or I . The complete code is: #define BOOST_SPIRIT_USE_PHOENIX_V3 #include <boost/spirit/include/qi.hpp> #include <boost/spirit/include/phoenix.hpp> #include <string> namespace qi = boost::spirit::qi; namespace spirit = boost::spirit; namespace ascii = boost:

Boost Qi Composing rules using Functions

微笑、不失礼 提交于 2019-12-02 04:01:55
问题 I'm trying to define some Boost::spirit::qi parsers for multiple subsets of a language with minimal code duplication. To do this, I created a few basic rule building functions. The original parser works fine, but once I started to use the composing functions, my parsers no longer seem to work. The general language is of the form: A B: C There are subsets of the language where A , B , or C must be specific types, such as A is an int while B and C are floats. Here is the parser I used for that

Boost spirit using local variables

跟風遠走 提交于 2019-12-02 02:34:45
I would like to define a rule based on a previously parsed value, i. e. the input string has the following structure: D <double number> or I <integer number> . I keep in a local boolean variable whether the first read character is D or I . The complete code is: #define BOOST_SPIRIT_USE_PHOENIX_V3 #include <boost/spirit/include/qi.hpp> #include <boost/spirit/include/phoenix.hpp> #include <string> namespace qi = boost::spirit::qi; namespace spirit = boost::spirit; namespace ascii = boost::spirit::ascii; using boost::phoenix::ref; template <typename Iterator> struct x_grammar : public qi::grammar

Add to a spirit qi symbol table in a semantic action

心不动则不痛 提交于 2019-12-01 22:49:03
问题 Going by the opening paragraph of the boost::spirit::qi::symbols documentation, I assumed that it wouldn't be too hard to add symbols to a qi::symbols from a semantic action. Unfortunately it appears to be not as straightforward as I would have assumed. The following bit of test code exhibits the problem: #define BOOST_SPIRIT_USE_PHOENIX_V3 #include <boost/spirit/include/qi.hpp> #include <boost/spirit/include/phoenix.hpp> #include <string> namespace qi = boost::spirit::qi; typedef qi::symbols