{"id":846,"date":"2010-01-13T08:34:25","date_gmt":"2010-01-13T16:34:25","guid":{"rendered":"http:\/\/boost-spirit.com\/home\/2010\/01\/13\/whats-the-difference-between-the-components-a-lita-and-char_a\/"},"modified":"2010-01-20T15:36:21","modified_gmt":"2010-01-20T23:36:21","slug":"whats-the-difference-between-the-components-a-lita-and-char_a","status":"publish","type":"post","link":"http:\/\/boost-spirit.com\/home\/2010\/01\/13\/whats-the-difference-between-the-components-a-lita-and-char_a\/","title":{"rendered":"What’s the difference between the Spirit components ‘a’, lit(‘a’), and char_(‘a’)?"},"content":{"rendered":"

While looking through the mailing list archives I realized that often the small issues get into our way. Small snippets of information are making the difference. So I decided to start a (more or less regular) series about small tips helping to get your work done while using Spirit<\/em>. Even if I sloppily call this series ‘Tip of the Day’, I by no means plan to have a tip a day.<\/p>\n

This time I’m going to highlight the difference between three different ways to parse or generate a single character: ‘a’<\/span>, lit(‘a’)<\/span>, and char_(‘a’)<\/span>.<\/p>\n

<\/p>\n

The first two forms, ‘a’<\/span> and lit(‘a’)<\/span> are semantically equivalent. Both create a component (a parser in Qi<\/em> and a generator in Karma<\/em>) handling the specified literal character, in this case the ‘a’<\/span>. As ‘a’<\/span> and lit(‘a’)<\/span> expose unused_type<\/span> as their attribute they can be used to match or generate a single ‘a’<\/span> without exposing or consuming an attribute value (remember, unused_type<\/span> is Spirit’s fancy way of saying ‘I don’t care’). This property makes the literal components very useful for matching and emitting characters not contributing to the semantics, such as comments in parsed source code, commas in the list of arguments to a function, etc.<\/p>\n

You might ask: ‘Why do you have two forms of expressing literals, then?’. The answer is readability. The first form (‘a’<\/span>)\u00a0 is simpler, costs less keystrokes to write and clearly expresses the intent to handle this character. So it is the preferred way of doing things. But unfortunately this isn’t syntactically possible all the time. Spirit<\/em> implements its domain specific embedded languages (DSEL’s) by directly utilizing the C++ language. This defines the constraints we have to work with. Let us have a look at the following example, where we want to match two characters in a row:<\/p>\n

\r\n'a' >> 'b'\r\n<\/pre>\n
This expression simply right shifts the bit pattern representing the character ‘a’<\/span> by the number of bits defined by the bit pattern representing the character ‘b’<\/span>. That is clearly not what we want! We need to have a way to tell the compiler that the expression has to be interpreted as a Qi<\/em> parser. Spirit<\/em> solves this dilemma by ‘tainting’ at least one of the terms:<\/p>\n
\r\nboost::spirit::lit('a') >> 'b'\r\n<\/pre>\n
Now we have a valid parser expression as the compiler is forced to invoke the proper overload of the right-shift operator as exposed by Spirit<\/em>.<\/p>\n
The third form, char_(‘a’)<\/span> distinguishes itself from the former ones by exposing its literal type as its attribute. This expressions used as a Qi<\/em> parser will expose the ‘a’<\/span> as the attribute value if it matched an ‘a’<\/span> in the input. If it is used as a Karma<\/em> generator it will succeed generating an ‘a’<\/span> either if no attribute is supplied or if the attribute value is ‘a’<\/span>, failing to generate otherwise.<\/p>\n
Share this:<\/h3>