Back to Real Life
Just over a month ago I ran into this problem. Before last month I hoped to never have to work on the C preprocessor or a parser generator. So much for that plan. Now my head is full of CPP-expansion-related trivia.
After a month of design and implementing changes to mcpp, elsa, elkhound and oink I can finally move on. During the last week all of the pieces of the puzzle finally came together ( without any nasty surprises other than bugs). Now I can go back to solving real problems.
Benefits of having CPP support don’t stop at actually being able to rewrite code. Now that the Oink C++ parser is aware of the C preprocessor, it should be possible to refactor C++ almost as easily as Java. Here are some cool things that are possible now:
- Nicer UI. Exact source position info allows for eclipse-style context menus for renaming & other refactorings in lxr (or other online code browsers).
- Richer type system. It should be possible to detect macro constants. Tools will be able to tell the difference between a prnull and 0. Should also be able to detect and maintain NSRESULT and other macros used for declarations.
- Macro refactoring. Now it’s possible to write a tool to automate the process of converting function-like macro calls to actual function calls. For example, PR_MAX could be converted into std::max calls with all of the accompanying casts to ensure that the resulting C++ is correct.
- Other nasty tricks like rewriting code within macro declarations.
I’m not sure how much of these features I will work on, but they are relatively easy to implement now.
I plan to write a minimalistic successor to squash and develop more aggressive refactorings than renames.
Additionally, I will continue pushing above changes upstream and trying to facilitate a more open oink development community.