Re: [Boost-users] Spirit and CTTL

From: Simon Buchan (simon_at_[hidden])
Date: 2005-09-28 19:46:08

Aaron Griffin wrote:
> On 9/28/05, Simon Buchan <simon_at_[hidden]> wrote:
> 
>>Aaron Griffin wrote:
>>
>>>Ok, I didn't go to school for computer programming, so I never had
>>>experience with a "Compilers" class or anything related to
>>>lexing/parsing.  But now I'm getting interested in it and have begun
>>>looking at some things.
>>>
>>>Spirit seems good, but it seems very weighty to work with.
>>>
>>>I was wondering if anyone has experiences with Spirit *and* CTTL and
>>>would be able to list for me some of the pros and cons of each.
>>>Spirit is, of course, a boost library and would be easier to find help
>>>and things of that nature, but CTTL seems to be a tad more lightweight
>>>(I'm not really sure).
>>>
>>>Thanks for any and all replies.
>>
>>Don't forget to put a link in:
>>http://cttl.sourceforge.net/
> 
> 
> Errrmmm... I could have *sworn* I put that link in there....
> 
> 
>> From what I've seen, this is MUCH harder to write grammars in, but
>>that's probably just because i'm not used to it.  Compare:
>>
>>Echo's back a Java/C++ program without it's comments:
>>http://cttl.sourceforge.net/example_cpp_comment_strip_cpp.html
>>Description of Spirit's comment matching facilities (amongst other
>>uses), A file that demonstrates it is linked at the bottom.
>>http://www.boost.org/libs/spirit/doc/confix.html
> 
> 
> Hmmm, I see now.  Of course, you have to ignore all the extraneous
> stuff in the CTTL example... and semantic actions and things like
> that.
> I actually started messing with both spirit and cttl on a similar
> parser (contrived syntax) and while the spirit one is much easier to
> write, there's syntactic things that bother me (+ would have been
> better than >> for sequence operator, overloading [] for semantic
> actions seems awfully arbitrary, and the requirement for
> my_grammar::definition seems unnessecary), but I guess that's what
> I'll have to live with, eh?

Pretty much all C++ restrictions (but all with good reasons).
The problem with + is mostly precedence, you would need much more 
brackets, also it matches their use in input/output.  op [] is used for 
pretty much no other reason than it's a postfix expression that takes 
one expression. (If they used (), you would get problems with the 
overloaded , op).
my_grammar::definition is so you can let the compiler figure out what 
type to use for the scanner (it's a metaprogramming idiom).  my_grammar 
effectivly is just a name tag for the compiler.
As a side bonus, sizeof(my_grammar) is effectively 0 (apart from the 
minimum object size restriction of 1).