Back in this post, I said about Spirit .. …it would be very feasible to write a lexical analyzer that makes a token object stream available via a ForwardIterator and write your grammar rules based on that. But is it ? really? The short answer is - Yes it is feasible, but probably not a good idea. The long answer is the journey we’ll take on the next two posts.
Dynamic Exceptions have their flaws. Herb Sutter has proposed a replacement known as Static Exceptions . Lets look at it a bit. Before we do, we need to look at the C+11 feature std::error_code std::error_code and Friends Anyone who has done any coding in C knows about good old errno, the global int that many system functions will set to signal a problem. This, of course, has many problems, not the least of which is that different platforms could and did use different integer values to represent the same error.
This time around, we will use a custom parser to handle the keywords. I really hadn’t planned on making this a series, but there you go. This will be the last - I think. Upgrades I started from the code from the last post, but did make a minor adjustment. I made underbar (’’) a valid character in an identifier. auto const ualnum = alnum | char('_'); auto const reserved = lexeme[symtab >> !
The ink hadn’t dried1 on my Identifier Parsing post when I realized that there was indeed a better way to handle multiple keywords. In that post I stated that a symbols<T> parser would not help because it suffered the same problem as lit(). Which is true. What I missed was that, of course, you could use the same trick with symbols as you did with lit() to make it work.
In Boost.Spirit X3, parsing identifiers is a bit tricky. If you are used to the distinction between lexical analysis and syntactical analysis (as I am), Spirit can take some getting used. Lexical analysis is done in the same grammar as the syntactical analysis. So the ubiquitous IDENT token type is now a grammar rule. To be sure, it doesn’t have to be this way. Spirit parsers work on iterator pairs, so it would be very feasible to write a lexical analyzer that makes a token object stream available via a ForwardIterator and write your grammar rules based on that.