views:

322

answers:

5

What is the problem that no industrial level refactoring tool for C/C++ have been created, I only need a tool that "just works"?

What I mean by "industrial level" is a quality provided by JetBrains products (IntelliJ, ReSharper), or above. Any available solutions (including Visual Assist from Tomato Software or Eclipse CDT) are not mature enough.

Below are advantages for a start-up to drive such a project.

  • alleviation of C++ boring syntax (making development more fun);
  • C++ is evolving (0x version is coming hence a lot of work for such tool implementers);
  • marketing niche is broader than anything else (a lot of written C++ code, a lot of active C++ projects), even taking into account Web (HTML/JavaScript) projects;
  • C++ is chosen for system problems where each bug found by tool at compile time is a survival (a lot of corporations or governments should be interested in);
  • such tool can decrease project compilation time;

The only drawback is technical challenges... but looking at what Google, Microsoft, Intel, etc. are doing, there should be no unsolvable technical problems.

    Lets summarize:
  1. it is possible to implement such product
  2. it is enormously profitable
  3. it doesn't exist

No one wants make a profit? Collusion ;) ? Whats is the reason?

+8  A: 

This link talks about some details and complexity involved

Chubsdad
"very complicated" doesn't mean impossible. Compilers **do** their job.
tivadj
"Very complicated" DOES often mean "too slow for real-time use".
MadKeithV
@tivadj @MadKeithV Case in point, Visual Studio Intellisense, which will bring your workstation to its knees with a moderately-sized C++ project.
Alex B
Linked article is not very relevant. The process does not need to be real-time. Visual Studio Intellisense is in fact a counterexample, as it relies on a precompiled `.ncb` file. _Its_ problem is that it can't keep the database clean, correct and also efficient.
MSalters
@MadKeithV asynchronous refactorings would be a saver
tivadj
@tivadj: asynchronous refactorings would just results in **continually** having to merge conflicts created by simultaneous edits.
Ben Voigt
+5  A: 

The reason is that C++ is not parseable by most common parsing techniques (LALR, LL, etc.) and actually requires some pretty heavy lifting to properly parse. Some tools like clang and gcc-xml make it possible for other tools to process C++ without implementing their own C++ parsers, although both are fairly new, and it can still be complicated to process C++ even with these parsing tools. I think that the industry will eventually see all the Java-related goodies ported/adapted to C++ ... the question is when.

Michael Aaron Safyan
It is more than just naked parsing that is the problem. You have to get name and type resolution right (and people often want you to do this having only partial access to the sources), and you have to be able to compute data flow information, including points-to analysis and call graph information. These are very sophiticated analyses, and parsers by themselves don't do this.
Ira Baxter
@Ira, right.. I was alluding to some of those issues when I wrote "it can still be complicated to process C++ even with these parsing tools."
Michael Aaron Safyan
+3  A: 

The problem is that C++ is hard to parse (its grammar is not context free) and hard to make any sense of without actually compiling the source. Java tools can work because the language is a lot simpler, both grammar and semantics.

wilx
Scratch "hard", replace with "impossible". The preprocessor alone can invalidate any assumption you make about the code without compiling it.
MadKeithV
And if you do run a preprocessor pass... your refactoring results end up with all macros substituted, etc. In fact, automated refactorings start to look a lot like compiler optimizations -- things like common subexpression and hot path refactoring are really nice but produce code that's no longer easy for a human to comprehend and edit.
Ben Voigt
Impossible in general, yes; practical, just fine. When the preprocessor is used abusively, the code is unreadable and unmaintainable, and pretty much people don't write that kind of stuff. It is worse with C than it is with C++, because C++ offers alternative abstraction mechaninisms. For a tool that can parse C (module badly misused macros/conditionals) and C++(pretty well), see our C++ front end: http://www.semanticdesigns.com/Products/FrontEnds/CppFrontEnd.html. Backed up by a robust program transformation tool, DMS. This has been to do massive C++ refactoring.
Ira Baxter
... the DMS parser *keeps* all the preprocesor directives. They aren't really different than the source code itself. You can apply transformations to them, and/or the source code.
Ira Baxter
+10  A: 

Let's consider just one basic refactoring: Rename function

The implementation appears very simple. Find all references, and replace the identifier used.

It gets a little more complicated with virtual functions. Now it's necessary to find the base declaration (and implementation, if not abstract), and references may be to any derived implementation in the class hierarchy. Much more difficult, but still feasible, because the group of functions to be renamed is well-defined.

That's the complexity that applies to languages like C# and Java. Now comes the kicker: C++ templates are duck typed. The set of implementations in the class hierarchy is no longer well-defined, because it could include ANY function with the same name and possibly compatible parameters. You did remember about Koenig lookup, right?

Trying to separate the list of functions which must have the same name, because they started out in the same overload resolution set, from those truly independent, would be an absolute nightmare. At this point you might as well just do a textual search-and-replace.

So let's go down your list of claims/desires:

  • "alleviate boring syntax". This is just trolling and means nothing in any technical sense. If the tool doesn't input and output C++ syntax, it's not a C++ refactoring tool.
  • "C++ is evolving". This means that such a tool would need to be maintained at considerable expense to keep up. It also means that a well-maintained tool would easily steal market share from older stable tools. And it means that any tool needs a ton of user configuration -- you don't want to generate C++0x-isms on a C++03 codebase after all -- so users will have to use the tool an awful lot to win back the time spent configuring.
  • "Each bug is a survival"? Not sure exactly what this grammatically nonsensical statement means, but perhaps it means zero bug tolerance? But that's best achieved by maintaining stability (the antithesis of automated refactoring that touches multiple files), solid architecture and documentation (which a refactoring tool won't automatically update, or do you want that too?), massive test suites, and static analysis. In fact, refactoring makes the massive test suites even more important, if that's possible, in order to verify that the tool didn't break anything. Note that automated static analysis faces some of the same challenges as refactoring, but since it doesn't change the code it can and does work on post-preprocessed code and/or compiler ASTs.
  • "decrease compilation time"? This is an unsupported claim in serious need of some evidence or at least solid reasoning. Are you expecting a refactoring tool to introduce pimpl for compilation firewalling? None of the C# and Java-style refactorings will reduce C++ compile time one whit.
  • "it is possible" No, actually it seems like it isn't. If you or I can't design one basic refactoring like Rename function in a sane manner, never mind implement it correctly, how can anyone implement dozens of them? If it is possible, it's also assuredly extremely expensive, which leads to:
  • "it is enormously profitable". Profitability requires not only a large base of users who are willing to pay for a product, but that the potential gross sales exceeds the costs. I claim you have seriously underestimated the costs so until you provide some real research on costs and markets I'll call this one wishful thinking as well.
  • "it doesn't exist". After going to some length to explain why such a tool can't exist, I'm now going to tell you that it already does? Yup. At least insofar as refactoring makes the final code better by doing things like hoisting common subexpressions outside loops, unrolling loops, exchanging order of iteration, inlining, cache optimization, vectorization, they are already provided by optimizing compilers, an area in which C++ leads both C# and Java by a wide-margin. C++ simply doesn't require many of the source-level tweaks needed in C# and Java in order to get a good final product. It's only the manipulation of source code to make it more accessible to humans that remains, and the existing tools do an adequate if not exception job of this.
Ben Voigt
Very. very good answer. Congratulations!
Didier Trosset
A: 

SlickEdit does it... never tried

AqD