Getting the Most Out of Eclipse CDT 3.0

Eclipse has emerged as the platform that finally integrates development tools from multiple vendors into a common, extensible, and widely supported framework. The Eclipse CDT development environment brings this rich offering of integrated tools to the world of C and C++ programming, enabling C/C++ developers to improve their productivity and enhance the quality of the software they produce.

The CDT project began in the summer of 2002 with source code donated by QNX Software Systems. Since then, developers from a number of organizations have contributed to the CDT, helping it evolve into a mature commercial-quality development environment. This diverse participation, which lets the CDT address the needs of a wide audience of developers, brings together the best minds in the C/C++ IDE industry.

In the summer of 2005, the CDT project team released CDT 3.1, which offers a feature set that closely matches the capabilities of other commercial and Open Source development environments. When designing version 3.1, the CDT team paid special attention to scalability for large development projects and laid the foundations that will allow the CDT to grow beyond the edit/compile/debug cycle of development.

This article walks through the CDT, with a special focus on features introduced in CDT 3.1. We'll also preview upcoming features that will make the CDT even more responsive and scalable than it is today. We'll then discuss the growing adoption of the CDT and how you can contribute to it.

CDT Overview
The CDT has three major components:

CDT Core
The CDT Core comprises several components, including project wizards, a source code editor, and a source code navigation system.
Project wizards

The project wizards help simplify the task of creating CDT projects. There is a wizard for each language (C and C++) (see Figure 1) and for each supported build system. Using the wizards, developers can quickly set the properties and build settings for a project, as well as enable or disable optional CDT features.

Source Code Editor
The CDT source code editor provides a modern feature set for browsing and editing C/C++ source. For instance, the editor:

With its built-in parser, the CDT provides a very accurate list of code completions based on the context of the code that the user is writing. (see Figure 2) This feature saves the time required to type in the completions and provides API assistance that frees the developer from having to rely on printed manuals.

Source Navigation
The CDT provides several features to help the developer navigate through the code in a project. These features are particularly useful when the developer is new to a project and doesn't necessarily know where certain pieces of code are defined or referenced. (see Figure 3)

The Document Object Model, or DOM, is at the core of the CDT's source-navigation features. The DOM provides a database of syntax and semantic information that's captured by the CDT's built-in parsers for C and C++. This database persists between sessions in an index that the CDT builds as files are saved in the file system.

The DOM supports several source navigation features, including:

The New Fast Indexer
For CDT version 3.1, a major restructuring has taken place surrounding the CDT's source indexing functionality that feeds information to many of the Source Navigation features. The new "Fast" indexer uses the CDT's internal parser to populate the index database. However, instead of doing full parsing as is done by CDT's "Full" indexer, the "Fast" indexer takes a number of shortcuts to reduce the amount of work that needs to be done to generate the index information. The most important short cut is to reuse parse information between files, thus eliminating the need to parser header files every time they were included in other files. With these heuristics, the "Fast" indexer is able to parser Mozilla in about a quarter the time than the Full indexer. In addition, index updates when file changes occur also benefit from this reuse of information, resulting in update times of under a second in most cases. In all, this leads to much better UI response times while working on C/C++ projects..

Integrating Third-Party Tool Chains
Using the managed build system, vendors can provide descriptions of their tool chains, including option settings and the file extensions of the files that the tools will use as input and generate as output. The CDT uses this information to adapt the property dialogs, allowing options to be set per project and per file. The CDT also uses this information, along with user settings, to generate the build files, usually makefiles, that are used for the build. Out-of-the-box the CDT provides integration with the prolific gcc tool chain for host development.

To support the DOM, the CDT needs build information to properly parse the source files in a project. The main information required consists of the header-file include paths and the command-line macro settings used by the preprocessor. For managed build projects, the CDT gathers this information from the user settings on the tool options. The managed build system will also determine and supply the built-in settings for the compiler being used for the build.


For standard build projects, determining build information is more difficult since in this case the CDT doesn't manage the build settings for the project. Thus, the project properties dialogs allow the developer to manually enter the include paths and macros. The CDT also provides a mechanism to automatically discover these settings; this mechanism will scan the build output, try to determine the build commands that are used, and extract the build information from there. CDT 3.1 introduces the option of importing a previously run build from which to extract the information. (See Figure 4)

To support multiple tool chains, both the standard and managed build systems support the setting of environment variables that are exported to the environment before running the build. Using this facility, the developer can change the PATH used to find compilers and linkers and set other environment variables that the build tools may require. (see Figure 5)

CDT Debug
The debug component of the CDT provides visualization of the debug session. A native debugger such as gdb handles the nuts and bolts of executing the application, setting breakpoints, and extracting variable values. Out-of-the-box, the CDT supports integration with gdb using gdb's MI text-based protocol. The CDT also provides an extensibility mechanism that lets other debuggers be integrated in the same way.

The CDT provides standard Eclipse visualizations for debug, including a list of threads, stack frames for currently paused threads, and variable values. CDT 3.1 introduces a new memory view from the Eclipse platform that supports a number of formats for memory values and enables the developer to browse more than one location at a time.

CDT 3.1 also introduces a new modules view (See figure 6) that shows the executable being debugged as well as the shared libraries and objects that the executable has loaded. The modules view can display any available symbol information, letting the developer set breakpoints on functions defined in the modules.

The CDT also provides a register view (see Figure 7) for C/C++ debugging. Version 3.1 extends this view by letting the developer organize registers into groups - especially useful for processors that have large numbers of registers.

Future Directions
With release 3.1, the CDT has reached a level of maturity that will ensure its widespread adoption by C and C++ developers. Nevertheless, the CDT team has planned some new features that will help the CDT become an even better IDE.

While the new ctags-based indexer can build an index for source navigation in dramatically less time, it suffers from less-than-perfect accuracy and doesn't capture references to identifiers. To address this problem and improve the performance of CDT's parser-based full indexer, the CDT team has developed a new strategy that allows the parser to make use of the results stored in the index. This way the parser can support most CDT features by parsing each file only once after the file changes. This approach will greatly improve the performance and scalability of large projects.

An interesting new Eclipse project is Photran, which is dedicated to building a Fortran IDE based on the CDT. To create the first version, however, the Photran team needed to clone the code in the CDT and then make changes to it. While some parts of the CDT, such as the managed build system, already offer multi-language support, the CDT team will add new extension mechanisms to make it easier for language developers to add new language support. This should allow the Photran team to build directly on the CDT and let them leverage the source navigation features of the CDT.

Joining the CDT Community
The CDT has a large and diverse community that contributes in a variety of ways. Committers, the people who have the power to change code, include members from QNX Software Systems, Intel, Texas Instruments, IBM, and Wind River. Other contributors contribute patches on a smaller scale, though these contributions are still critical to the success of the CDT. These contributors include HP, Siemens, and Symbian. A number of other contributors contribute by testing, submitting bug reports, and requesting enhancements.

In October 2005, QNX hosted a CDT Contributors Summit in Ottawa. Members of over 20 major organizations participated, representing the embedded, enterprise, and scientific/research segments of the C/C++ market.

The CDT is used in many places and by many people. Recently, we recorded 130,000 downloads of the CDT in a two-month span, including 50,000 downloads of CDT 3.1.1 in the two weeks following its release. These numbers represent a significant portion of the Eclipse community in general, proving again that the scope of Eclipse extends far beyond Java development.

The CDT community is always open to more contributions. For up-to-date information and instructions on how to contribute, visit http://wiki.eclipse.org, then click on "CDT Project" in the projects list. Contributors also meet on the cdt-dev@eclipse.org mailing list to discuss technical issues and make program decisions.

© 2008 SYS-CON Media