{"id":1355,"date":"2011-02-26T10:35:32","date_gmt":"2011-02-26T18:35:32","guid":{"rendered":"http:\/\/boost-spirit.com\/home\/?p=1355"},"modified":"2011-02-26T11:29:10","modified_gmt":"2011-02-26T19:29:10","slug":"using-_val-in-top-level-semantic-actions","status":"publish","type":"post","link":"http:\/\/boost-spirit.com\/home\/2011\/02\/26\/using-_val-in-top-level-semantic-actions\/","title":{"rendered":"Using _val in Top Level Semantic Actions"},"content":{"rendered":"

Frank Dellaert was asking a valid question on the Spirit mailing list where he pointed out some things he was not able to understand. His question clearly uncovered an inconsistency in Spirit\u2019s<\/em> API. This lead us to implement some minor additional feature, which in the end turned out to make more uniform the way semantic actions are handled.<\/p>\n

<\/p>\n

Given the following definitions:<\/p>\n

\r\n#include <boost\/spirit\/include\/qi.hpp>\r\n#include <boost\/spirit\/include\/phoenix.hpp>\r\n\r\nnamespace qi = boost::spirit::qi;\r\nnamespace phoenix = boost::phoenix;\r\n\r\nclass Point3\r\n{\r\n    double x_, y_, z_;\r\npublic:\r\n    Point3() : x_(0), y_(0), z_(0) {}\r\n    Point3(double x, double y, double z) : x_(x), y_(y), z_(z) {}\r\n};\r\n\r\nPoint3 pt3;\r\nstd::string input("1.0,2.0,3.0");\r\n<\/pre>\n
He showed that this piece of code works fine:<\/p>\n
\r\nqi::rule<std::string::iterator, Point3()> r =\r\n    (qi::double_ >> ',' >> qi::double_ >> ',' >> qi::double_)\r\n    [\r\n        qi::_val = phoenix::construct<Point3>(qi::_1, qi::_2, qi::_3)\r\n    ];\r\nqi::parse(input.begin(), input.end(), r, pt3);\r\n<\/pre>\n
At the same time, this code does not compile:<\/p>\n
\r\nqi::parse(\r\n   input.begin(), input.end(),\r\n   (qi::double_ >> ',' >> qi::double_ >> ',' >> qi::double_)\r\n   [\r\n       qi::_val = phoenix::construct<Point3>(qi::_1, qi::_2, qi::_3)\r\n   ],\r\n   pt3);\r\n<\/pre>\n
The only difference between the two is that in the first case the parser is wrapped into a rule, while in the second example the parser is directly placed inline into the parse()<\/span> API call. After some investigation I understood, that the placeholder qi::_val<\/span> was only usable in semantic actions attached to some right hand side of a rule. In this context, it referred to the rule\u2019s attribute.<\/p>\n
After some discussions on IRC we decided that this limitation in the behavior of qi::_val<\/span> is unneeded and confusing. It turned out that the fix is simple and does not break any existing code. The change, which will be available starting with the next release of Boost (V1.47), has been committed to SVN already. With this change in place it is possible to use the placeholder qi::_val<\/span> in top level semantic actions as well, where it will refer to the whole attribute passed in by the user. This now allows to compile the second code example from above.<\/p>\n
Please feel free to try it in your code! Note that the fix has been applied not only to Qi\u2019s<\/em> set of parse()<\/span> API functions, but also to Karma\u2019s<\/em> set of generate()<\/span> functions.<\/p>\n
Thanks again to Frank for bringing up this detail, which in the end stirred some interesting discussions and which made Spirit a bit easier to use.<\/p>\n
Share this:<\/h3>