>> It is somewhat irritating to me that there is almost no comments >> for this: it seems well thought out and written. Is there any out >> of line documentation available? > > Asking around there doesn't seem to be any that I could find. > Sorry :(
Ok. >> Overall, it is an impressive piece of work. There are some minor >> strange (to me) design decisions: for example, what is >> ConditionAST, why does it exist? > > Sorry I am not that familiar with the design choice, I have forwarded > this to Roberto who will hopefully respond shortly with answers to it > and the other ones below. Thanks, >> The ASTs produced seem to be a bit heavier-weight than the clang >> ASTs, and relies on the entire lexed token stream being available >> to interpret the location info. However, in my first few minutes >> looking at it, I don't think that it shares the "fatal flaws" (from >> the clang perspective only, obviously) in its design or >> implementation that elsa has. As a matter of fact, while the >> details differ significantly, its design is somewhat similar to >> clangs, validating clang's design ;-). One thing that is >> impossible for me to do from inspection is to determine how >> complete the parser is. >> >> Since I don't have it built and you do, here are some questions for >> you: :) > > Having it sitting in the middle of other packages is getting > annoying. I have pulled it out and made a quick (and very dirty) > example app that can be used to generate preprocessed files (./ > example -E file) put it in a git depot and put it up online > > http://repo.or.cz/w/rpp.git Nice, it's easy to get a tarball from it, unfortunately I don't have qmake. >> 1) looking at the preprocessor, the implementation doesn't look >> particularly speedy. It is using std::strings to push text >> around. Have you timed the preprocessor on large inputs to see how >> fast it really is? > > Did a quick (not scientific) test against gcc on my macbook it is > almost twice the speed > > g++ > real 0m0.437s > user 0m0.243s > sys 0m0.060s > > rpp > real 0m0.248s > user 0m0.197s > sys 0m0.070s User+sys it is only 13% faster. Still this is impressive :) >> 5) it looks like a lot of semantic checks are missing. Is there >> anything that talks about the current state of the parser? It also >> reads and ignores lots of stuff, even simple things like break/ >> continue/goto stmts. > > I know that there are several groups (kdevelop is one group) who wish > to use it to parse c++ code beyond Qt so it will be maintained and > improved. I don't know their plans though. Sorry I can't be more > help. No problem, I'll delve more into the code. It looks like it is designed and optimized for use by kdevelop, so it hasn't focused much on type analysis and other things that a front-end needs for full diagnostics and code generation. However, it has a pretty nice design and is simple, so it's a good source of inspiration. Now we just need someone to help push C++ support forward! :) -Chris _______________________________________________ cfe-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
