boost-spirit

I want to write a parser (as a qi extension) which can be used via my_parser(p1, p2, ...) where p1, p2, ... are qi parser expressions. Actually, I want to implement a best_match parser which works like qi alternative, but selects not the first matching rule but the rule which 'explains' most of the input. Given two rules simple_id = +(qi::alpha) and complex_id = simple_id >> *(qi::string("::") > simple_id) it would select complex_id on the input willy::anton . And it would not produce intermediate attributes while doing so. These benefits get payed for with runtime because lookahead parsing is

I'm looking for the simplest way to implement variadic function which takes list of boost::spirit::qi rules and expands the list into expression of format: rule1 | rule2 | rule3 |.... Let's assume that the rules synthesize no attribute. Your kind help is very much appreciated. #include <boost/config/warning_disable.hpp> #include <boost/spirit/include/qi.hpp> #include <string> #include <iostream> #include <boost/spirit/include/phoenix_operator.hpp> namespace qi = boost::spirit::qi; namespace ph = boost::phoenix; namespace ascii = boost::spirit::ascii; using boost::spirit::qi::phrase_parse;

I am trying to use the Boost Spirit X3 directive repeat with a repetition factor that is variable. The basic idea is that of a header + payload, where the header specifies the size of the payload. A simple example “3 1 2 3” is interpreted as header = 3, data= {1, 2, 3} (3 integers). I could only find examples from the spirit qi documentation. It uses boost phoenix reference to wrap the variable factor: http://www.boost.org/doc/libs/1_50_0/libs/spirit/doc/html/spirit/qi/reference/directive/repeat.html std::string str; int n; test_parser_attr("\x0bHello World", char_[phx::ref(n) = _1] >> repeat

I am using Boost::Spirit to build simple "data-filter" language in my C++ GUI application for non-technical users. Language is very similiar to plain English and parse-able into AST. I am requested to make the process as user-friendly as possible, so I wish to provide CLang-like error messages ("Unrecognized 'tokken', did you meant 'token'?") and autocompletion. The question in place is how to use Boost::Spirit grammar to generate possible token list for both goals (I will use simple string distance algorithm to satisfy first requirement)? My ideas so far: Add position and length in source

I am learning to use boost::spirit library. I took this example http://www.boost.org/doc/libs/1_56_0/libs/spirit/example/qi/num_list1.cpp and compiled it on my computer - it works fine. However if I modify it a little - if I initialize the parser itself auto parser = qi::double_ >> *(',' >> qi::double_); somewhere as global variable and pass it to phrase_parse, everything goes crazy. Here is the complete modified code (only 1 line is modified and 1 added) - http://pastebin.com/5rWS3pMt If I run the original code and pass "3.14, 3.15" to stdin, it says Parsing succeeded, but with my modified

I'm trying to integrate CUDA to an existing aplication wich uses boost::spirit. Isolating the problem, I've found out that the following code does not copile with nvcc: main.cu : #include <boost/spirit/include/qi.hpp> int main(){ exit(0); } Compiling with nvcc -o cudaTest main.cu I get a lot of errors that can be seen here . But if I change the filename to main.cpp , and compile again using nvcc , it works. What is happening here and how can I fix it? nvcc sometimes has trouble compiling complex template code such as is found in Boost, even if the code is only used in __host__ functions. When

I have this very simple parser using Boost::Spirit: rule<std::string::iterator, std::string()> zeroTo255 = (string("25") >> char_('0', '5')) | (char_('2') >> char_('0', '4') >> digit) | (char_('1') >> repeat[2](digit)) | (char_('1', '9') >> digit) | digit; When I try to parse std::string o{"1"}; std::string s; parse(o.begin(), o.end(), zeroTo255, s); std::cout << o << ": " << s << std::endl; I have as output 1: 111 I'm obviously doing something wrong, but what? qi::hold is one way about it, as correctly mentioned by @Andrzej I think I have a few observations that might help, as well as a