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 - helps developers create, edit, and navigate projects
• CDT Build - integrates with build tools to create executables for projects
• CDT Debug - integrates with native debuggers to help developers debug those executables

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:

• Colorizes keywords and literals in the source code
• Displays the location of matching brackets and braces
• Offers code-formatting features for shifting code left and right and for commenting and uncommenting out lines of code
• Provides code completion - the user can type the prefix of an identifier and then select from a list of possible completions for that identifier

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:

• C/C++ Projects View - Helps the developer navigate projects by providing a C/C++-centric view of source code, elements, and libraries.
• Outline View - Shows declarations from source files. If the developer clicks on a declaration, the source-code editor will "jump" directly to the source line where the declaration occurs.
• Search features - For looking up declarations, definitions, and references to identifiers defined in the source code or entered through dialogs. The developer can browse the search results. If the developer clicks on a result, the source code editor will jump to the corresponding point in the source file.
• Source-code refactoring - Lets developers change the structure of their code without changing its behavior. The most common form is rename refactoring, which propagates an identifier name change to all uses of that identifier. By using the DOM, the refactoring engine makes intelligent decisions to ensure that the changes don't cause compile errors.

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.