Related work on C/C++ refactoring

Posted Jan 30, 2009 19:24 UTC (Fri) by tglek (guest, #56374)
In reply to: Related work on C/C++ refactoring by padator
Parent article: Semantic patching with Coccinelle

Not to make this a contest, but some refactorings require writing a C++ tool, some already have such tools.

So for the rename it'd be a matter of running
./renamer ::alloca ::malloc on the files of interest

For the other change, who knows could be a few lines of C++ or could be a few thousand depending if the complexity of the attempted change(pork's changes can be as complex as the user desires due to having a fully elaborated AST).

to post comments

Related work on C/C++ refactoring

Posted Jan 30, 2009 19:42 UTC (Fri) by tglek (guest, #56374) [Link]

I should mention that Pork also does not require the user to teach it about various preprocessing constructs used. I know Mozilla code features some phenomenally bad macro expansions(ie defining while method bodies within macros.. or building function bodies out of various macros or otherwise having macros concatenation to call functions) most of which would be extremely unpleasant to explain to any parser.

Instead Pork allows detection of code where macros interfere with a particular refactoring so it can produce an error message and inform the user that some manual help is needed for that particular bad macro. Usually that turns out to be a trivial amount of effort(in the worst possible case it took a couple of days to compensate for it).

Related work on C/C++ refactoring

Posted Jan 30, 2009 19:50 UTC (Fri) by padator (guest, #56235) [Link]

And will your renamer tool also rename code inside ifdefs ? If I run it on the linux kernel, will it also rename functions in arch/alpha/... or
protected by #ifdef DEBUG ?

Coccinelle has also internally a fully elaborated AST and one can write any transformations in OCaml working on this AST but this is precisely what we want to avoid with Coccinelle. We don't want users to express their transformations on the AST but instead to express it easily using our SmPL patch syntax.

Also you didn't really answer my question, how long will it take using Pork to express the second program transformation mentioned in val's article about renaming malloc and also adding the pointer checking code for NULL.