Eclipse CDT – 2006-06-27

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

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.

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.


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.