''Maybe the average C++ programmer doesn't need it.'' There are several listed at RefactoringBrowserForCeePlusPlus, including * SlickEdit * Ref++ The following discussion of why people believed this to be the case may still be of interest. ---- The only thing worse than C++ is Perl. Write a parser for either one? Yuk. Not to mention no orthogonal(?) rule set. * ''A well-known axiom in the Perl community is "only perl [the interpreter] can parse Perl [the language]", and not without reason.'' ''Yeah. I doubt that anyone is ever going to make that big an investment. It would certainly be helpful to C++ users (I've wished for a C++ refactoring browser myself) but you're better off coding in a language with fewer than a million reserved words and syntax quirks. (Hasn't anyone yet invented a language like C++ without all the warts? Nobody answer "Java", please...)'' *DeeLanguage. *ObjectiveCee ''(I don't think so. ObjectiveCee is much more Smalltalk-like than C++-like.)'' *CsharpLanguage ;-) ''(No cigar - C# is compiled to an intermediate language, not close enough to the metal.)'' [C# ''is'' more C++-like than Java, with structs, #directives, and especially with impending generics support - BUT this contention is ill-conceived. A language which is "close to the metal" can allow, for instance, as C++ does, a client to access a class's data by taking a pointer to the object, casting to void*, then offsetting the correct number of bytes, casting to T* and dereferencing. How could any sane refactoring browser work in this kind of environment? I realize that of course 99.9% of C++ program(me(r))s don't use this kind of thing, but an automated refactoring tool should only provide provable non-behaviour-changing program transformations. Which is approximately nothing at all in C++. In C# you can mark blocks as unsafe to do nasty pointer things (that a refactoring browser wouldn't want to look at). Perhaps a refactoring browser for C# could work by ignoring those parts of the code.] On the other hand, in Smalltalk one can also access instance variables by offset, using #basicAt:put:. I don't believe the original Refactoring Browser handles such abominations, so why should the C++ one be any better? * ModulaThree C++ without the warts: that'd be the CeeLanguage! ...and after you remove the warts, hack off your legs below the knees. ---- Hasn't anyone yet invented a language like C++ without all the warts? ''What if the warts are inherent in the AlgolFamily?'' Nah. The Algol Family is mostly a syntactic category used to describe languages with begin-end or the equivalent, such as C braces. The semantic issues don't seem to matter as much: Lisp has statements thanks to PROGN etc, C or even Java with first class functions and closures still wouldn't be Lisp, Vaughn Pratt called his Lisp-with-block-structure "Cgol", not "Block Lisp", etc. Beyond begin/end syntactic structures, there's too much variety in "The Algol Family" for the members to have much in common. It's always hard to draw sharp definitional lines...from 20,000 feet, what's really the difference between C's { ... } and Lisp's (LET ... )? They both define a syntactic scope which can contain functions and/or statements, in both languages. The big issue for Refactoring Browsers has already been described above: any traditional systems programming language that can manipulate general pointers is just too unconstrained to be able to offer any guarantees that code modifications won't change the semantics of the program. ''True, a refactoring browser wouldn't be able to prove that its changes were safe, but then the programmer can't do that either. What you can do (in either case) is rerun the tests to *verify* that the changes didn't affect the semantics of the program.'' ---- CategoryRefactoringBrowser