C++ refactoring tools?

Short answer: C++ is probably the most difficult programming language to parse (does anyone know a more complicated language anyway?). This leads to the lack of automated tools. I'd *love to* refactor my C++ code the way I do Java code in Eclipse, but I understand that writing such tools is a major pain, especially with templates.

-- Mikko

Thats not an answer, thats an excuse. :P

Yes I know how tricky C++ is to parse, especially when you start dealing with the more obscure areas of templates and whatnot, but it seems like no-one is even interested in one, never mind actually trying to make it work.

Have a look at Whole Tomato the beta of their next version has a whole bunch of refactoring stuff for Visual Studio.

Quote:

Original post by spookycat Have a look at Whole Tomato the beta of their next version has a whole bunch of refactoring stuff for Visual Studio.

Ha, I'll believe that when I see it. Visual Assist is buggy as hell and deeply unstable, I wouldn't trust it to get even of the most simple of refactorings right.

In other news, I've just been trying Ref++ and it can't even do a rename class correctly. Ho hum.

Cant say Ive ever had any problems with Visual Assist, I havnt used the refactoring version yet but it is used by other coders here and they seem convinced by its worth :)

Quote:

Original post by OrangyTang Quote: Original post by spookycat Have a look at Whole Tomato the beta of their next version has a whole bunch of refactoring stuff for Visual Studio. Ha, I'll believe that when I see it. Visual Assist is buggy as hell and deeply unstable, I wouldn't trust it to get even of the most simple of refactorings right. In other news, I've just been trying Ref++ and it can't even do a rename class correctly. Ho hum.

My experiences with Visual Assist X has been very positive. Visual slickedit includes some refactoring tools but obviously is not VS2005 based.

Quote:

Original post by spookycat Cant say Ive ever had any problems with Visual Assist, I havnt used the refactoring version yet but it is used by other coders here and they seem convinced by its worth :)

The cpp->h switching gets confused easily if you've got mapped drives, likewise with 'go to definition'. 'Go to definition' also gets confused with namespaces and can't tell distinct classes with the same name apart. And the on-the-fly error reporting gets out of sync at the drop of a hat.

(Although to be fair, the latest version has stopped randomly disabling itself for no reason, so at least it's stable now)

There has been a great discussion about refactoring tools on sweng-gamedev some days ago. You can find the archives here.

Why do you want to refactor your code once its working correct?


Whats your definition of "refactor" making the code to look clean? or to elimiate awful code constructs?


P.S.: Me is using a highly customized vim with tons of appreviations and such

Quote:

Original post by Basiror Why do you want to refactor your code once its working correct? Whats your definition of "refactor" making the code to look clean? or to elimiate awful code constructs?

Wikipedia entry on Refactoring.

Typically, it involves changes for the purpouse of reducing the costs of:

1) Mantinence (debugging, modification, or hooking in unit tests, often via "cleaning up" the code in question)
2) Extensibility (by factoring out special cases and seperating them from the reusable, reducing boilerplate repetition)

It is a very broad category covering a large slew of potential changes.

So in other words the best way of refactoring is to follow a good coding style in the first place.

I really wonder how an application can help you with refactoring the code after finishing the implementation of the specification

Thats quite a hard job for human beings, what makes it even harder for computers.

Google for Ref++. It's cheap and stable...

Slickedit on the other hand never mangaed to parse a ~10000 LOC project...

Edit: Ok, the OP mentioned Ref++ already...

[Edited by - TrueTom on July 19, 2006 12:24:58 PM]

Quote:

Original post by Basiror So in other words the best way of refactoring is to follow a good coding style in the first place.

No, you've completely missed the point. Refactoring is more than just good style, it covers every area of your program code. Refactoring is about transforming one particular implementation into another, where both implementations produce identical output.

Programming is (largely) about trade offs. Performance vs. memory. Readability vs. performance. Flexibility vs. ease of use. Abstraction vs. control.[1] Refactoring takes you (in small increments) from one to another. Maybe a particular set of assumptions was correct at the start of the project, but now things have changed. Maybe what we've created is flexible, but flexes in the wrong way. Sooner or later, all software must change or become inadaquate.

Quote:

I really wonder how an application can help you with refactoring the code after finishing the implementation of the specification

The initial implementation is only the first step. I could program tens, hundreds even, of solutions to any given problem but you probably wouldn't care which one I chose. But then later requirements change, and it becomes desirable to mutate one into another (or a combination of). Refactoring lets you achive this goal.

Quote:

Thats quite a hard job for human beings, what makes it even harder for computers.

The whole point of refactoring is that it doesn't change the overall behaviour. It's akin to optimisation (in fact, optimisation could be classed as a particular kind of refactoring). Because of this it's very possible to develop tools that can transform one implementation into another (and do so knowing that the result is actually identical to the original).

I find it hard to believe you're not just trolling. If all the projects you've worked on you've finished an implementation and walked away you've been very lucky (or you've been very stubborn and not willing to change something thats already written).

[1] Ok, sometimes there is an obvious 'best' solution, but at some point all changes start to trade one important property against another, and the 'best' solution is highly dependant on the goals of the actual problem and end user. Hence the prevalance of my language vs. your language threads.

Quote:

Original post by OrangyTang Anyone know of any good refactoring tools for C++? I know Eclipse has some, but I'm stuck with VS2005 here, so it's either got to be a plugin or a standalone tool.

Just because you use vs.net as your compiler/debugger/project manager doesn't mean you can't use ecllipse as your refactoring editor. I use emacs as my editor and vs.net does all my file management( vsproj ) building( cc/link ) and debugging.

I can't see why Ecllipse isn't an option for you:)

Cheers
Chris

[Edited by - chollida1 on July 19, 2006 5:55:46 PM]

Quote:

Original post by OrangyTang The whole point of refactoring is that it doesn't change the overall behaviour. It's akin to optimisation (in fact, optimisation could be classed as a particular kind of refactoring). Because of this it's very possible to develop tools that can transform one implementation into another (and do so knowing that the result is actually identical to the original).

I thought more about a automated process that transforms your code/implementation into another one, by analyzing the given input and transforming it with the wp-calculus in mind.
But if you are only talking about a little application that merges or splits the code into several functions/classes then its of course possible

Quote:

Original post by OrangyTang I find it hard to believe you're not just trolling. If all the projects you've worked on you've finished an implementation and walked away you've been very lucky (or you've been very stubborn and not willing to change something thats already written). [1] Ok, sometimes there is an obvious 'best' solution, but at some point all changes start to trade one important property against another, and the 'best' solution is highly dependant on the goals of the actual problem and end user. Hence the prevalance of my language vs. your language threads.

a) When I program I usually start with a certain aim in mind, usually an implementation that fits into my project's need but still has a common interface as you know it from similar implementations.
b) When writing the code I always think about parts of the code that could be "refactored" into seperate functions/classes ... for the sake or reuseability.
c) Looking at the final code, I can claim that its pretty well documented, clean written and pretty easy to understand in the most cases.
d) As you know most of the code you write once in a while can be refactored away into a base code library and thats what I am usually doing during development.
I start with a little specification, think about common interfaces for the know problem, implement it, unit test it and finallyy I judge whether its work to move it into the base code library.

Till now I didn t come into a situation where I had to refactor my base code in any way, its pretty solid atm. This might change in the future, but I usually try to make it as general as needed which really saves a lot of work.


My strategy is to avoid the need of refactoring in the first place, unfortunately this comes with a little trade off, longer production times in the beginning.

Work just has to be done before your profit from your results:)

Quote:

Original post by Basiror My strategy is to avoid the need of refactoring in the first place, unfortunately this comes with a little trade off, longer production times in the beginning. Work just has to be done before your profit from your results:)

I think you'll find that once you start working with a larger team with varying skill levels and have to release version 12 of your product with internet features that version 1 wasn't designed to include( because the internet didn't exist yet) you'll find that refactoring is a must.

Regardless of howmuch upfront planning you do:)

But if not, then can I have a job at your company:)??

Cheers
Chris