This page will contain FAQ entries which will eventually be incorporated into the FAQ section of the documentation.<\/p>\n
Question:<\/strong> I am trying to assign a rule, y, to another rule, x:<\/p>\n This fails at runtime with a Boost Assertion saying that I’m trying to initialize a rule from an uninitialized one. What is happening?<\/p>\n Answer:<\/strong> Spirit 2 rules conform to ‘proper’ C++ copy\/assign semantics. This gives you the freedom to copy\/store\/assign your rules as you do any C++ object (pass them as arguments, return them from functions, store them in STL containers, etc). This is a major difference between Classic Spirit<\/em> and Spirit 2<\/em>.<\/p>\n You are trying to assign a rule (in the c++ sense instead of the BNF sense) to a different instance of the same type. There is no way to directly deduce your intention of referring to the right hand side rule instead of making a (C++) copy. So in this situation you need to write:<\/p>\n to make the lhs a ‘logical’ copy of the rhs (and not a copy in the pure C++ sense).<\/p>\n Question:<\/strong> Hmm… then how about<\/p>\n should there be alias too?<\/p>\n Answer: <\/strong>No. Only when there is a single rule in the RHS.<\/p>\n Question: <\/strong>I wrote a spirit parser to read in a file which acts as a parameter file for a finite-element simulation code. The file itself has approx. 200 to 300 lines but the grammar for this is quite large, because you have very few repetitions in the job-file.<\/p>\n During the implementation I discoverd that the compilation process needs more and more memory (and time) with increasing grammar. Right now I need 8GB at peak, to compile the parser!<\/p>\n Is there a way to reduce the ram needed for computation? The machines where I have access easily have up to 8GB RAM only.<\/p>\n Answer: <\/strong>With gcc, the debugging information uses up a lot of ram. Try compiling with the ‘-g0’ flag.<\/p>\n Question:<\/strong> I store identifiers in a symbol table. My problem is that prefixes are being incorrectly matched. I don’t want that. For example, if I have an identifier named “bat” in the symbol table, “battery” is being incorrectly parsed as “bat” followed by a trailing “tery”. Is there a way to allow whole identifiers only?<\/p>\n Answer: <\/strong>Sure. The not-predicate is your friend. Check out calc6 code, for example:<\/p>\n ensures that a variable does not follow an alnum or underscore.<\/p>\n Question:<\/strong> Why do I have to specify the attribute for rules and grammars using the strange function declaration style:<\/p>\n Answer:<\/strong> This syntax is equivalent to:<\/p>\n The C++ specs call it a ‘type-id’ “which is a declaration for an object or function of that type that omits the name of the object or function”.\u00a0We usually\u00a0call it function declaration syntax<\/em> (even if it probably should be called function type-id syntax<\/em>). It is used not only in Spirit but by several other libraries as well (see boost::function for instance).<\/p>\n The main reason for this is not because we wanted it that way, but because it is a nice and concise way of specifying a function interface. If you think about what a rule is, you quickly realize that it is like a function: it may return a value (the parsed result, i.e. synthesized attribute). Additionally, it may take one or more arguments (the inherited attributes).<\/p>\n A second, but minor reason is that we need to be able to distinguish the different template parameters of a rule. The template parameters can be specified in any order (except for the iterator), so we need some means of figuring out what’s what. The function declaration syntax is sufficiently different from the skipper or the encoding to allow it to be recognized at compile time.<\/p>\n Question:<\/strong> If a rule matches, and thus executes its semantic actions, but a rule which includes that rule mismatches, there seems to be no way to “unwind” the code executed down the chain. For example, if one of your semantic actions allocates memory or increments a reference count, how do you free\/release that reference in the mismatch scenario?<\/p>\n Answer:<\/strong> Sure:<\/p>\n If p fails with side-effects from its direct or indirect semantic actions, the cleanup semantic action can roll them back.<\/p>\n Question: <\/strong>There are times when you want to parse, say, a number or provide a default if it isn’t in the input. How can you do that? (Thanks to Robert Stewart and Michael Caisse for this entry)<\/p>\n Answer: <\/strong>The parser for that value is optional, so the usual mechanism is something like this:<\/p>\n (The ‘s’ parser is present just to illustrate that there can be more expected to follow the optional part of interest.)<\/p>\n The problem is how to provide a default value should there be no number (and whatever follows it). A naive approach is the following:<\/p>\n Because there’s a semantic action in that rule, attribute compatibility rules are disabled. Thus, %= is needed rather than =. Secondly, the assignment must be lazy, so This can be done more easily using Question<\/strong>: I have this rule:<\/p>\n where both a<\/em> and b<\/em> and the r<\/em> have an attribute which is a container (e.g. std::vector). When a<\/em> fails and Qi backtracks and tries b<\/em>, it doesn’t clear the vector before trying the second alternative and the final attribute ends up doubled. That seems like a bug to me.<\/p>\n Answer<\/strong>: If a<\/em> fails, then it backtracks and tries b<\/em>. The side-effect being that the work done by a<\/em> is not rolled back. Why is the action not undone? Well, for the sake of efficiency. We’ve found that it is very expensive to roll back the attribute to its original state on a failed match. Doing so would involve lots of copying and swapping. Consider this pseudo code:<\/p>\n Take note that you always pay for that extra copy every time!<\/p>\n To be very honest with you, we are actually violating a post condition required by parsers where: On a failed match, the attribute is left untouched. You can still see this in the docs until 2.4.2<\/a>. Now, to avoid further confusion, this post condition has been changed to:<\/p>\n On a failed match, the attribute state is undefined.<\/strong><\/p><\/blockquote>\n And with that, it will be clear that when a<\/em> fails, we make no guarantee that the attribute will be in a consistent state. Actually, if you think about it, it is the same as:<\/p>\n where when a<\/em> fails, it does not roll back what it has already done by f<\/em>. So, there’s really consistency with how semantic actions work.<\/p>\n How do you deal with cases like this? The hold <\/em>directive is your friend: see Parser Directive for Attribute Commit\/Rollback<\/a>. For example:<\/p>\n hold <\/em>does the saving and swapping for you.<\/p>\n Question<\/strong>: I have this start rule:<\/p>\n This parser works great using qi::phrase_parse. However, parsing fails when I refactor the RHS into another rule and use an alias of that in my start rule:<\/p>\n What am I doing wrong?<\/p>\n Answer<\/strong>: A rule needs to know what skipper to use. Calling a rule inside phrase_parse which has no skipper is equivalent to an implicit lexeme[] around its right hand side. You don’t want that. You need to declare your vec rule with a skipper, just as you did with your start rule:<\/p>\n\r\nx = y;\r\n<\/pre>\n
\r\nx = y.alias();\r\n<\/pre>\n
\r\nx = eps >> y;\r\n<\/pre>\n
\n<\/a>Large Memory Consumption Compiling Spirit Parser on g++<\/a><\/h3>\n
\n<\/a>Correctly Parsing Identifiers<\/a><\/h3>\n
\r\nvariable =\r\n (\r\n lexeme[\r\n vars\r\n >> !(alnum | '_') \/\/ make sure we have whole words\r\n ]\r\n )\r\n<\/pre>\n
\n<\/a>Rule and Grammar Attributes<\/a><\/h3>\n
\r\nqi::rule<Iterator, std::string(), skipper> r;\r\n<\/pre>\n
\r\ntypedef std::string f_type();\r\nrule<Iterator, f_type, skipper> r;\r\n<\/pre>\n
\n<\/a>Semantic Action for Mismatches<\/a><\/h3>\n
\r\nr = p | eps[cleanup];\r\n<\/pre>\n
\n<\/a>Parse Or Supply a Default<\/a><\/h3>\n
\r\n-(uint_ >> 's')\r\n<\/pre>\n
\r\nrule<Iterator, unsigned()> s;\r\ns = (uint_ >> 's') | eps[_val = 0];\r\n<\/pre>\n
boost::phoenix::val()<\/code> must be used:<\/p>\n\r\ns %= (uint_ >> 's') | eps[_val = val(0)];\r\n<\/pre>\n
boost::spirit::qi::attr()<\/code>, however, which obviates the semantic action and thereby eliminates the need for %=. This leaves us with the following simple solution:<\/p>\n\r\ns = (uint_ >> 's') | attr(0);\r\n<\/pre>\n
\n<\/a>Alternatives and Attributes<\/a><\/h3>\n
\r\nr = a | b;\r\n<\/pre>\n
\r\nAttr save = attr;\r\nif (parse(f, l, attr)) \/\/ if successful\r\n{\r\n return true;\r\n}\r\nelse\r\n{\r\n swap(attr, save);\r\n return false;\r\n}\r\n<\/pre>\n\r\nr = a[f] | b[f];\r\n<\/pre>\n
\r\nr = hold[a] | b;\r\n<\/pre>\n
\n<\/a>Skipper-less Rules in Phrase Parsing<\/a><\/h3>\n
\r\nqi::rule<iterator_type, qi::space_type> start;\r\nstart = (int_ % ',');\r\n<\/pre>\n
\r\nqi::rule<iterator_type> vec;\r\nvec = (int_ % ',');\r\nstart = vec.alias();\r\n<\/pre>\n
\r\nqi::rule<iterator_type, qi::space_type> vec;\r\n<\/pre>\n
Share this:<\/h3>