Code Vamping This blog will deal mainly with Software development topics with C++ being a major focus. However, a bit of music will be thrown in from time to time for spice. Needless to say, something that combines both will definitely fit. The main point of this site is to give me an outlet to explore technologies and topics that don’t really fit into my day job. The Technology The site is built with the following techologies (and others):
Color chart to explore options for style this site.
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.
I thought I would take a moment and document my current development environment. The main computer runs windows 10. However, the development computer is actually a VirtualBox ArchLinux client running on that Win 10 box. I use X11 Forwarding to display back to an cygwin/X server running on the host. I am currently using Codelite as my IDE, though it has some rough edges. GNU compiler suite rounds things out.
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.
So, I decide to join the blogging crowd. It remains to be seen if it sticks. Why? I’ve been doing some home-brew software development lately and found that there were some things I wanted to say and no place to say them. So here is that place. This won’t be all about software development. There will undoubtedly be some music-ish things thrown in. And things about music software and probably software music too.