Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 179391

Summary: Refactoring Support for C/C++
Product: [Tools] CDT Reporter: Robert Gravina <robert>
Component: cdt-coreAssignee: Project Inbox <cdt-core-inbox>
Status: RESOLVED FIXED QA Contact:
Severity: enhancement    
Priority: P3 CC: emanuel
Version: 4.0   
Target Milestone: 5.0   
Hardware: Macintosh   
OS: Mac OS X - Carbon (unsup.)   
Whiteboard:

Description Robert Gravina CLA 2007-03-26 17:08:35 EDT 
Just reviving an old topic for discussion - the possibility of improving refactoring support for C/C++ in CDT.

A previous proposal was made a while back:
https://bugs.eclipse.org/bugs/attachment.cgi?id=14995

I suspect this won't be an easy task, but we can discuss what would be involved in implementing some more refactorings (e.g. need for a rewriting engine), and what refactorings users would find useful.

My initial thinking was to attack C-specific refactorings before C++, but I'm not sure at this stage if that makes things any easier, since CDT and the LTK provide many useful services. I am new to the Eclipse framework, so excuse my ignorance (for the timebeing!).

A few possible refactorings (some ideas taken from work here: https://netfiles.uiuc.edu/garrido/www/CRefactory.html):

- Function-related
Manipulating function arguments, inlining a function, extracting a series of statements or expression to a function call (i.e. extract function)

- Variable-related
Change scope of a variable, replace variable with constant, add pointer to variable.

- Struct-related
Manipulating struct fields, converting a group of local variables to a struct. 

I realise refactoring C/C++ is not all roses, thanks to the pre-processor, among other problems. I'll post again once I've had a chance to look into this further.
Comment 1 Markus Schorn CLA 2007-03-27 03:38:02 EDT 
The question on what refactorings to start with is a matter of taste, I have no preferences. There are a couple of subproblems that have to be solved:

* How to generate the Change/Edit structure that is required by the refactoring
  framework. For the rename-refactoring it is sort of hand-crafted. As we add
  more refactorings there is some commonality that should be done in a common
  place. JDT handles that with a class that is named 'ASTRewriter' or similar.

* How to handle inactive code (#ifdef xx #endif), for which we do not have any
  information in the index. For the rename refactoring I use a text-search to
  be able to warn the user that there are potential matches. Is that the way to
  go?

* How to deal with the fact that the information in the index is not (and will
  never be) perfect. Again in the rename-refactoring this is backed by the text-
  search that finds the places where the parsing fails. We could also think 
  about storing problems we find during indexing in the index.
Comment 2 Robert Andrzejuk CLA 2007-04-03 18:06:39 EDT 
bug 75364 - has a more updated version of Refactoring requirements.
But still this document is from the end of 2004!

I believe CDT is at the stage where it's very usable :) and for the user to make full use of modern IT knowledge he should be able to REFACTOR.

Maybe start small and then grow?

If at the moment there is a problem with the preprocessor in various places of code, why not write refactoring commands which do not work on code which has conditional defines? Simply warn the user and do nothing.

Because, as I see it ... 3 yrs from know, people are still going to be discussing the problems and not fixing any problems.
Comment 3 Markus Schorn CLA 2008-04-16 10:28:34 EDT 
We are now handling each refactoring in a separate bug:
e.g.: bug 226658, bug 226646, bug 226490, bug 226484.

Marking this bug as fixed.