© scx.hu

Anpassungsfähigkeit ist die herausragende Eigenschaft der IDE Eclipse. Das CDT-Plugin macht sich dies zu Nutze und adaptiert die Workbench für die Sprachen C und C++. Heraus kommt eine ergonomische Entwicklungsumgebung mit nützlichen Zusatzfunktionen.

Eclipse sei eine IDE für alles und auf nichts spezialisiert – so beschreiben die Eclipse-Entwickler die Zielsetzung ihres Projekts. Aber erst Plugins wie die C/C++ Development Tools (CDT, [1]) erwecken die Software richtig zum Leben: CDT adaptiert das Eclipse-Framework für die verbreiteten Sprachen. Das Plugin nutzt die Funktionalität der Workbench, etwa die flexible Unterfensterverwaltung oder das Autocompletion-Popup im Editor, passt sie an die Programmiersprachen C und C++ an, etwa das Syntax-Highlighting des Editors, und fügt noch den Prozessorregister-Monitor, den Disassembler oder die Überwachung für festgelegte Speicherbereiche hinzu.

Schreibhilfe

Ein an die Sprache angepasster Editor erleichtert das Schreiben von Programmcode: Syntax-Highlighting weist bereits auf Tippfehler hin, wenn der Cursor noch an der richtigen Stelle steht. Autocompletion ist bei C++-Programmen mit vielen Klassen besonders angenehm. Das Highlighting des CDT-Editors versteht außer C- und C++-Syntax auch die Anweisungen in Makefiles.

Im Dateibrowser hebt Eclipse Syntaxfehler ebenfalls hervor: Fehlerhafte Dateien sowie Ordner und Projekte, die solche Dateien enthalten, markiert die Anwendung mit einem roten Kreuz. Obwohl die Icons klein gehalten sind und in der Workbench für den Editor genügend Platz lassen, zeigen sie den Objekttyp, den Status der Syntaxprüfung und beim Einsatz einer Versionsverwaltung auch den Synchronisationsstatus an.

Auch die Autocompletion-Funktion erbt das ergonomische Look&Feel von Eclipse: Das CDT-Plugin kennzeichnet die Vervollständigunsvorschläge durch Icons gut erkennbar als Klassen, Methoden, Variablen oder Schlüsselwörter der Programmiersprache (Abbildung 1). Voraussetzung dafür, dass der Code-Assistent Klassen und Methoden erkennt, ist jedoch, dass Eclipse das entsprechende Include-Verzeichnis kennt. Oft, aber nicht immer reichen die automatisch erkannten Include-Pfade hierfür aus. Wählt der Anwender in der Popup-Liste eine Funktion oder Klasse, zeigt der Editor deren Signatur an.

Auf der Suche

Die Suchfunktion arbeitet dank einer Indizierung im Hintergrund zügig. Der Indiziervorgang selbst ist mit der seit Version 3.1.1 vom Herbst 2006 enthaltenen, verbesserten Variante des Indexers schneller geworden: Den gesamten Firefox-Quellcode, der aus über 10000 Dateien mit C- oder C++-Quellcode besteht, liest er auf einem aktuellen Rechner in weniger als drei Minuten ein. Die Suchfunktion differenziert nach Syntaxelementen wie Klassen, Methoden, Funktionen, Variablen und Feldern. Nützlich sind die Working Sets, die eine Suche auf Untermengen der Projektdateien beschränken.

Die normale Suchen-und-Ersetzen-Funktion aus dem Eclipse-Basiscode ist im CDT-Editor zwar verfügbar, wird aber kaum gebraucht, denn ein Refaktoring-Werkzeug, das beim Umbenennen den syntaktischen Status des zu ersetzenden Begriffs berücksichtigt, also zum Beispiel zwischen gleichnamigen Variablen und Funktionen unterscheidet, erledigt dessen Aufgabe.

Mit Hilfe des schnellen Indexers arbeitet das Refaktoring-Werkzeug auch bei großen Projekten, also zum Beispiel bei dem Firefox-Quellcode, effektiv: Das Umbenennen einer Klasse, die in etwa 10000 Dateien ungefähr 350-mal angesprochen war, ging auf dem Testrechner, einem AMD Athlon 64 3700+ mit 2 GByte RAM, schon in deutlich weniger als fünf Minuten über die Bühne.

Gut strukturiert

Neben der Suchfunktion hilft die Outline-Ansicht (Abbildung 2) bei der Orientierung im Quellcode: Sie bietet einen Überblick über Strukturen wie Includes, Variablendeklarationen und Klassen. Symbole verdeutlichen den Objekttyp. Der Dateibrowser zeigt die Einträge der Outline-Ansicht als Unterelemente der Dateien an. Eine farbige Randmarkierung hilft die Änderungen seit dem letzten Speichern nachvollziehen.

»Navigate | Last Edit Location« setzt den Cursor an die zuletzt bearbeitete Stelle. Allerdings speichert diese Funktion nur eine Position, nicht wie ein Webbrowser eine ganze Entwicklungsgeschichte. Last but not least unterstützt der Editor das Ausblenden von Code in Unterstrukturen wie Schleifen oder Funktionsdefinitionen und kommentiert Zeilen oder Blöcke auf Knopfdruck aus.

Baustelle

Die C/C++ Development Tools automatisieren wie bei integrierten Entwicklungsumgebungen üblich den Build-Prozess. In der Standardeinstellung bindet Eclipse die normale GNU-Make-Workchain mit ein. Das Build-Framework in CDT setzt das architektonische Prinzip, das die ganze Eclipse-Workbench durchzieht, fort: Die Kommunikation mit den GNU-Compiler-Werkzeugen findet über eine erweiterbare Plugin-Schnittstelle statt. Die Implementierung der GNU-Build-Chain lässt sich daher mit relativ wenig Programmieraufwand für andere Build-Systeme wie Cmake abwandeln.

Während des Build-Vorgangs parst die IDE die Ausgabe des Build-Tools, die auch im Konsolen-Unterfenster sichtbar ist (Abbildung 3). Die Software erkennt, bei welcher Quelldatei das Kompilieren gescheitert ist, und kennzeichnet diese im Dateibrowser mit einer Fehlermarkierung. Nach dem Kompilieren durchsucht Eclipse das Projektverzeichnis nach Binärdateien. Wie für Quelldateien enthält der Dateibrowser auch hier Untereinträge: Er listet alle Sourcedateien, aus denen das Executable oder die Library entstanden sind.

Bei den Projekttypen »Managed C-Project« und »Managed C++-Project« kümmert sich die Software um die Erstellung von Makefiles und der anderen für die GNU-Build-Tools erforderlichen Dateien. »Unmanaged C-Project« und »Unmanaged C++-Project« eignen sich für jene importierten Projekte, bei denen bereits ein Makefile existiert. Sie lassen sich auch nachträglich in Projekte mit Makefile-Management umwandeln. Für das händische Erstellen beziehungsweise Anpassen der Makefiles steht ein eigener Editor zur Verfügung.

Jagd auf Fehler

Für C und C++, bei denen nach Programmabstürzen keine Fehlermeldung des Runtime-Environment Aufschluss darüber gibt, wo der Fehler steckt, ist der Debugger ein wichtiges Hilfmittel. Eclipse bindet von sich aus den GNU-Debugger Gdb ein. Wie bei der Build-Chain ist es dank der Extension-Points aber auch möglich, andere Lösungen in Eclipse zu integrieren.

In der CDT-Workbench finden Entwickler die üblichen Debugger-Funktionen: Ein Doppelklick auf den Zeilenrand im Quelltexteditor setzt einen Breakpoint, bei dem der Programmablauf abbricht. In der Variablenansicht zeigt Eclipse bei angehaltenem Programm die Werte der Variablen (Abbildung 4). Ein Debug-Cursor markiert im Quelltext die Stelle, an der das Programm angehalten hat. Hilfreich bei Schleifen mit vielen Durchläufen sind Watchpoints: Diese halten den Programmablauf nicht an einer bestimmten Stelle an, sondern dann, wenn die Variablenwerte bestimmten Bedingungen entsprechen.

Lückenlose Überwachung

CDT unterstützt auch einen Einzelschrittmodus. Der Anwender entscheidet dabei, ob der Debugger auch per »include« eingebundene Teile des Code Schritt für Schritt ausführt oder nur die Befehle in der Top-Level-Datei. Wenn das zu debuggende Programm pausiert, darf er die Variablenwerte auch per Hand verändern.

Da es sich bei C und C++ um vergleichstweise maschinennahe Sprachen handelt, erweitert CDT das Eclipse-Debug-Framework um eine Prozessorregister-Ansicht, eine Funktion zum Überwachen bestimmter Speicherbereiche sowie um einen Disassembler.

Besser als ihr Ruf

Früher eilte Eclipse der Ruf voraus, träge und instabil zu arbeiten. Das veranlasste CDT-Projektleiter Doug Schaefer in seinem Vortrag für die Eclipsecon 2006 [2] zu dem Vorschlag, als Test den Quellcode von Firefox als Eclipse-C++-Projekt zu importieren, zu kompilieren und zu bearbeiten. Das positive Resultat bestätigt, dass der schlechte Ruf spätestens seit Eclipse 3.2 nicht mehr zutrifft: Die Workbench reagiert nach dem Laden des Projekts weiterhin zügig. Dass das Eclipse-Binary und die Java Virtual Machine zusammen über 300 MByte RAM beanspruchen, ist bei der Größe des verwalteten Projekts in Ordnung. Der schnelle Indexer für Suche und Refaktoring trägt auch zu dem guten Eindruck bei. Programmabstürze sind wesentlich seltener geworden. Einmal verabschiedete sich die IDE im Test zu diesem Artikel dennoch.

Eclipse und das CDT-Plugin bilden zusammen eine leistungsfähige IDE für die Entwicklung in C und C++: Die flexible und übersichtliche Workbench, der Editor sowie die Such- und Refaktoring-Funktion wirken insgesamt ausgereift, sie sind intuitiv zu bedienen und beschleunigen das Arbeiten.

Schade ist aber, dass Eclipse und CDT den Anwender beim Erstellen von grafischen Oberflächen allein lassen: Programmierer, die einen GUI-Editor benötigen, müssen entweder auf externe Programme zurückgreifen oder statt Eclipse andere IDEs benutzen: Kdevelop [3] enthält einen leistungsfähigen GUI-Editor für Qt-Widgets, für Anjuta [4] gibt es ein experimentelles Plugin für GTK-Oberflächen. Einen Überblick mit unter Linux verfügbaren IDEs bietet [5].