{"id":949,"date":"2010-01-31T15:16:59","date_gmt":"2010-01-31T23:16:59","guid":{"rendered":"http:\/\/boost-spirit.com\/home\/?p=949"},"modified":"2010-03-11T19:39:25","modified_gmt":"2010-03-12T03:39:25","slug":"what-is-the-attribute-type-exposed-by-a-parser","status":"publish","type":"post","link":"http:\/\/boost-spirit.com\/home\/2010\/01\/31\/what-is-the-attribute-type-exposed-by-a-parser\/","title":{"rendered":"What is the Attribute Type Exposed by a Parser?"},"content":{"rendered":"

Most questions on the main Spirit mailing list<\/a> are centered around attributes and how to correctly utilize Spirit’s<\/em> attribute propagation rules. We discussed the related\u00a0basics in several posts already, but many people still have problems to understand the rules. Somebody recently asked on the mailing list whether it would be possible to print the attribute type exposed by an arbitrary parser expression. I answered by posting a sketchy code snippet (see here<\/a>), but afterwards I realized it might be a good topic for yet another ‘Tip of the Day’.<\/p>\n

<\/p>\n

Before you read on, please be aware that the interfaces described in this post are not set in stone and may change in the future without attempting to be backwards compatible. I’ll write about the current implementation anyway as I think those are important. Generally, understanding attribute handling is crucial to understanding Spirit<\/em>. Nuff said.<\/p>\n

Naturally, Spirit<\/em> internally implements the means of retrieving the attribute type of any parser expression. So all we need to do is to invoke those and wrap them into a nicely reusable tool.<\/p>\n

Let us start by briefly describing some implementation details related to parser construction and attribute composition. As you might already know, any parser expression provided by the user (such as for instance\u00a0qi::int_ >> qi::double_<\/span>) is not something you could directly\u00a0use to parse input. The qi::int_<\/span>, qi::double_<\/span>, etc. are just placeholder symbols denoting the type of the parser component required to match the input. These parser expressions have to be compiled into real parser instances responsible for the actual matching of the input. Spirit has a built in facility boost::spirit::compile<\/span> which performs the conversion of the parser expression into the corresponding parser instance. Here is the (simplified) prototype:<\/p>\n

\r\nnamespace boost { namespace spirit\r\n{\r\n    template <typename Domain, typename Expr>\r\n    typename result_of::compile<Domain, Expr>::type\r\n    compile(Expr const& expr);\r\n}}\r\n<\/pre>\n
where Domain<\/span> is a tag type which in our case is qi::domain<\/span>, thus identifying Qi<\/em> (i.e. telling the function we want to create a parser), and Expr<\/span> is the parser expression to compile. As most (meta-) template facilities in Spirit the compile<\/span> construct consists out of two parts: the meta-calculation of the resulting type of the parser instance (result_of::compile<\/span>) and the actual function doing the runtime compilation. For the purpose of this post we are interested in the resulting type of the parser instance only.<\/p>\n
Among other things, after compiling the parser expression, the member function parse()<\/span> is called on the returned parser instance. In the article about Creating Your Own Parser Component for Spirit.Qi<\/a> we saw that the parser instance additionally exposes its attribute type. Spirit<\/em> implements another facility we can invoke to extract this attribute type for a given parser instance type:<\/p>\n
\r\nnamespace boost { namespace spirit { namespace traits\r\n{\r\n    template <typename Component, typename Context = unused_type\r\n      , typename Iterator = unused_type>\r\n    struct attribute_of;\r\n}}}\r\n<\/pre>\n
where Component<\/span> is the type of the parser expression to query for its attribute type, the Context<\/span> is not relevant in our case and Iterator<\/span> is the iterator type used to do the actual matching. Most parser components are independent of any iterator type, but components as the raw[]<\/span> directives are. So most of the time we can leave out supplying an iterator type.<\/p>\n
These two Spirit facilities are all what we need! Let us combine the two in order to get the type of the attribute exposed by a parser created from a given parser expression.<\/p>\n
\r\ntemplate <typename Expr, typename Iterator = spirit::unused_type>\r\nstruct attribute_of_parser\r\n{\r\n    typedef typename spirit::result_of::compile<\r\n        spirit::qi::domain, Expr\r\n    >::type parser_expression_type;\r\n\r\n    typedef typename spirit::traits::attribute_of<\r\n        parser_expression_type, spirit::unused_type, Iterator\r\n    >::type type;\r\n};\r\n<\/pre>\n
Now as we have a tool to get the attribute type, we can use a simple utility function to print it out to the console (in this example we ignore the iterator type):<\/p>\n
\r\ntemplate <typename T>\r\nvoid display_attribute_of_parser(T const&)\r\n{\r\n    typedef typename attribute_of_parser<T>::type attribute_type;\r\n    std::cout << typeid(attribute_type).name() << std::endl;\r\n}\r\n\r\n\/\/ this will print something like: boost::fusion::vector2<int, double>\r\ndisplay_attribute_of_parser(qi::int_ >> qi::double_);\r\n<\/pre>\n
That’s it! We created a nice, reusable function printing the attribute type of an arbitrary parser expression. I added this as an example to the Boost SVN here<\/a> and here<\/a>, allowing you to reuse it for your needs. The last thing to mention is that a similar utility can be easily written for Karma<\/em> generators. The only thing to change is the passed Domain<\/span> which needs to be spirit::karma::domain<\/span>.<\/p>\n
Share this:<\/h3>