Cpp Programmierung

Aus Physik
Zur Navigation springen Zur Suche springen

Compiler und IDEs

Qt

Eine Klassenbibliothek und Entwicklungsumgebung für Programmierung graphischer Benutzeroberflächen.

gtkmm

C++ Interface zu GTK+

Debuggen von C/C++ Programmen

Besonders die Speicherzugriffsfehler (Segmentation Faults) können schwer zu finden sein. Es gibt aber Tools mit denen die Fehlersuche wesentlich schneller und weniger frustrierend verläuft.

valgrind

Valgrind ist ein Programm, das die ganze CPU emuliert, es verfolgt jeden einzelnen Zugriff auf den Speicher, den das zu testende Programm macht. Ungültige Speicherzugriffe (z.B. über das Ende eines Arrays hinausschreiben) werden auf der Konsole ausgegeben und können im Quellcode sofort ausgebessert werden. Die Verwendung ist ganz einfach:

  $ valgrind <das_zu_testende_programm>

Die Meldungen von valgrind sind etwas kryptisch, es wird aber alles klar, wenn man sich das kurze howto durchliest. (hier ist noch ein howto) Das zu testende Programm muss natürlich mit dem flag -g (fürs debuggen) kompiliert sein. Da die cpu emuliert wird, läuft das programm ungefähr 20 mal langsamer. Sollte für das testen aber kein Problem sein. Valgrind ist im Computerraum natürlich installiert.

core dump

Nach einem Speicherzugriffsfehler kann man Linux dazu veranlassen einen sogenannten "core dump" abzuspeichern. Es ist eine Datei die einfach 'core' heißt. In diesem File, das dann in dem Verzeichnis abgespeichert wird, von wo das Programm gestartet wurde, befindet sich der vom Programm verwendete Arbeitsspeicher, so wie er zum Zeitpunkt des Programmfehlers gerade gesetzt war. Man kann sich also den Variableninhalt zum Zeitpunkt des Fehlers anschauen. Außerdem bekommt man auch die Programmzeile, in der der Fehler aufgetreten ist.
Der core dump wird standardmäßig nicht abgespeichert, es muss erst eine Konsole aufgemacht werden, und dort mit dem Befehl ulimit die maximale Größe des core dump festgelegt werden. Diese Einstellung gilt dann aber nur für die eine Konsole! Nach dem Schließen der Konsole ist alles wieder auf Standardeinstellung!
Der Befehl

  $ ulimit -c 20000

stellt die maximale core dump Größe auf 20MB.
Nun führt man (in der gleichen Konsole!) das fehlerhafte Programm aus, das mit einem Speicherzugriffsfehler beendet wurde. Es wird automatisch ein core file angelegt.

Jetzt braucht man nur ein Debugger Programm um dort die Sourcefiles anzugeben und den core dump zu laden, damit man sich den Zustand des Programms zum Zeitpunkt des "Programmabsturzes" ansehen kann. Das weitverbreitetste Debugger ist "ddd". Lässt sich einfach in der Konsole mit dem Befehl

  $ ddd

starten. Alternativ kann man auch mit der Entwicklungsumgebung

  $ kdevelop

arbeiten. Auch dort kann man den core dump laden und das Programm debuggen. Wie bei Valgrind, sollte das Programm mit dem -g flag (für Debuginformationen) kompiliert sein.

Profiling von C/C++ Programmen

Mit Hilfe des Profiling lässt sich herausfinden an welchen Stellen/Funktionen das C/C++ Programm wieviel Zeit verbraucht. Die Engpässe können leicht erkannt und eventuell im Quellcode optimiert werden, damit die Anwendung schneller läuft. Führen Sie zuerst ihre Binary im Callgrind aus:

  $ callgrind <Ihre_Anwendung>

Im Callgrind wird genau wie im Valgrind die CPU und sämtliche Speicherzugriffe nachsimuliert, weshalb die Anwenung bei dieser Analyse viel langsamer laufen wird. Callgrind erzeugt eine Datei mit den Profiligergebnissen callgrind.out.eine_zahl:

Diese können im kcachegrind visualisiert werden:

  $ kcachegrind callgrind.out.eine_zahl

Weitere Informationen gibt es im Internet: kcachegrind



Plotten von Daten aus C (oder C++)

Quellcode Formatierung

Mit dem Tool indent lässt sich der "Coding Standart" von C/C++ (Anzahl der Leerzeichen für Tabulator Einrückungen, Automatisches Einrückungen in Funktionen usw.) automatisch an die üblichen Standards anpassen. Man braucht nur

 $ indent <quellcode_datei.c>

oder

 $  indent *.c

ausführen. In der Standardeinstellung wandelt indent dabei den C-Sourcecode gemäß der "GNU Coding Standards". Ein anderer schöner Style wäre z.B.

 $  indent -gnu -bli0  -i8 <quellcode_datei.c>

Da verschiedene Entwickler, Projekte oder Unternehmen oft unterschiedliche Formatierungen aufgrund ihrer Gewöhnung als besser lesbar einschätzen, kann dies sehr nützlich sein.

Grundlegende Themen

C Fehler - Bugs - Probleme

Links