After working in TextWrangler (and a bit in XCode) for a couple of weeks, I really started to miss Eclipse. So I installed CDT. After almost two weeks, I am not satisfied. In fact, I am disappointed.

On the Goodness of Eclipse

Before 2003, I had written Java in BBEdit Lite, (X)Emacs and Project Builder. I hadn’t seen anything better. In 2003, I was introduced to NetBeans. The moment was epiphanic. Later that year, I tried Eclipse. First, I could not use it, due to CVS problems, but after the CVS issues were resolved, it was obvious that it was even better than NetBeans (well, at the time, at least).

The Eclipse JDT is extremely powerful and has improved my Java productivity immensely. It seems weird that in the old days, I wrote Java without Eclipse. Now writing Java without Eclipse seems unbearable. The interesting thing with Eclipse is that it makes Java development so great that in some cases, it is easier to attack problems in Java even though in terms of languages Python might be more suitable. Though Java is terribly verbose for writing in a text editor, with JDT’s autocompletion and templates, writing Java in Eclipse may take less work than writing Python in TextWrangler.

Much of JDT’s coolness derives from the integration of the compiler with the editor. The integration of the compiler front-end in the editor makes context-aware errors messages and autocomplete possible. It also makes smart refactoring—full with liveness analysis of variables, etc.—possible. And it enables smart search that is based on static analysis of the code (what code calls what, etc.). And it works great! Moreover, running the compiler back end in the background while editing cuts away the time of waiting for builds. When you want to launch, the classes are already there.

But while NetBeans is a Java IDE, Eclipse is more like the Emacs of the new millennium. So far, everything worth developer attention had to have an Emacs mode. Now, everything worth developer attention should have an Eclipse plug-in. For example, I use TeXlipse for my BibTeX and LaTeX needs.

My Expectations

I was expecting to get the Eclipse experience with C++. I was expecting the IDE to fulfill the function of LXR. A couple of years ago when I was modifying a large Java app written by others, a big part of my productivity was thanks to the code comprehension features of JDT. I was also expecting CDT to provide a working gdb front-end. I was expecting to get error markers in margins. I was also expecting some refactoring support albeit not as good as with Java.

On the Brokenness of CDT

• CDT is way too eager to do full builds. I fooled it to doing incremental builds when it thinks it is doing full ones. That’s probably the wrong way to curb full builds, but I had to do something.

• XCode can debug Firefox just fine through gdb. Eclipse cannot. Firefox behaves badly on launch. It relaunches itself. Eclipse can’t connect to the process after the relaunch.

• Eclipse wants to rebuild when launching a debug target. I can’t figure out how to prevent it without breaking the ability to build in general.

• JDT takes away most of the pain caused by deep Java package directory hierarchies. No such luck with CDT and the Mozilla module directory structure.

• The indexer is slow. (Improvement coming, though.)

• The identifier search is slow. (Why isn’t it as fast as on the JDT side once the index is built?)

• Even an incremental build pokes everything in the whole source tree. CDT isn’t smart about the Mozilla make hierarchy, so it can’t use the knowledge of which source files changed.

• Moreover, the build involves make and gcc instead of a compiler integrated in the editor.

• The refactor menu is sad compared to JDT.

• Autocomplete is so horrendously slow (SBBoD for one minute upon each invocation) that it cannot be used.

• Can’t figure out how to make tab insert two spaces!

In fairness, most of the brokenness of CDT results directly from the brokenness of C++. C++ has all kinds of pathologies that make sane IDE support really hard.

• The C++ compiler would be totally lost on its own, so it needs make sitting in front of it and hand-holding it through the build moving the compiler further from the IDE.

• C++ separates declarations in header files, but there can be definitions in headers and declarations in non-headers.

• C++ has a preprocessor, which can do things that e.g. cause identifiers not to appear as whole strings in the source files. Also conditional compilation means that it is hard to figure out whether a given line participates in the program.

• C++ has templates, which can make it hard to track what is going on.

• Mozilla has additional complications like generating headers from IDL.

• Even though there is a standard, compiler-specific subsetting of the standard is important enough that you can’t trivially substitute compilers.

Solving the Problems in Theory

It seems to me that solving some of the key problems would be a huge undertaking. First, CDT would need to implement GNU make–compatible functionality so that it could drive the build itself and learn the dependencies from makefiles in order to build in smart increments. Second, to support quick error reporting, smart autocomplete and refactoring, CDT would need to have a full C++ compiler front-end integrated into the editor. Developing such a thing would be even more difficult that developing a standalone non-interactive C++ compiler front-end.

If that could be pulled off, throwing in non-optimizing compiler back-ends for key platforms wouldn’t be such a big deal.

Anyway, getting CDT on par with JDT is not a small task.

Conclusion

The only thing that I expected and that worked was putting the error marker in the margin. And even that involved running make, which is slow with Mozilla.

I am rather disappointed and have spent too much time on this tool. Still, I think that CDT is the best candidate for a sane C++ IDE and, with time, it may get better. Unfortunately, so many important pieces of software are written in C++ that it is futile to wish the problem (C++) away.