Cpp Programmierung: Unterschied zwischen den Versionen

Aus Physik
Zur Navigation springen Zur Suche springen
Zeile 79: Zeile 79:
 
*[http://www.ba-stuttgart.de/~boehm/NoBugs/www/NoBugs/ recht umfangreiche Linksammlung]<br>
 
*[http://www.ba-stuttgart.de/~boehm/NoBugs/www/NoBugs/ recht umfangreiche Linksammlung]<br>
 
*[http://www.lysator.liu.se/c/ten-commandments.html 10 Gebote des C Programmierens]<br>
 
*[http://www.lysator.liu.se/c/ten-commandments.html 10 Gebote des C Programmierens]<br>
*[http://courses.iicm.edu/index.html Vorlesungen am IICM], <br> [http://courses.mbi.tugraz.at/ElektronischeLiteratur/ Unterlagen vom Maschinenbauinstitut] (wo Klaus Schmaranz jetzt arbeitet) <br> darunter C und C++ Einführungsvorlesungen:
+
*[http://courses.iicm.edu/index.html Vorlesungen am IICM]
  +
*[http://courses.mbi.tugraz.at/ Unterlagen vom Maschinenbau- und Betriebsinformatikinstitut] (wo Klaus Schmaranz jetzt arbeitet) <br> Leider derzeit nicht mehr zugänglich, vielleicht kommt's ja wieder: <br> Unterlagen zu C und C++ Einführungsvorlesungen:
 
**[http://courses.mbi.tugraz.at/ElektronischeLiteratur/SoftwareentwicklungInC.pdf Skriptum zu Einführung in die strukturierte Programmierung (früher Programmieren0)] '''C'''<br>Dies ist das Buch "Softwareentwicklung in C" von Klaus Schmaranz!
 
**[http://courses.mbi.tugraz.at/ElektronischeLiteratur/SoftwareentwicklungInC.pdf Skriptum zu Einführung in die strukturierte Programmierung (früher Programmieren0)] '''C'''<br>Dies ist das Buch "Softwareentwicklung in C" von Klaus Schmaranz!
 
**[http://courses.mbi.tugraz.at/ElektronischeLiteratur/SoftwareentwicklungInCplusplus.pdf Skriptum zu Softwareentwicklung - Praktikum (früher Programmierpraktikum)] '''C++'''<br>Dies ist das Buch "Softwareentwicklung in C++" von Klaus Schmaranz!
 
**[http://courses.mbi.tugraz.at/ElektronischeLiteratur/SoftwareentwicklungInCplusplus.pdf Skriptum zu Softwareentwicklung - Praktikum (früher Programmierpraktikum)] '''C++'''<br>Dies ist das Buch "Softwareentwicklung in C++" von Klaus Schmaranz!

Version vom 12. März 2007, 08:25 Uhr

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 langsammer. 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' heisst. In diesem File das dann in dem Verzeichniss 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 standartmäsig nicht abgespeichert, es muss erst eine Konsole aufgemacht werden, und dort mit dem Befehl ulimit die maximale Grösse des core dump festgelegt werden. Diese Einstellung gilt dann aber nur für die eine Konsole! Nach dem Schliessen der Konsole ist alles wieder auf standarteinstellung!
Der Befehl

  $ ulimit -c 20000

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

Jetzt braucht man nur ein Debugger Programm, dort die Sourcefiles angeben, und den core dump laden, und kann sie den Zustand des Programms zum Zeitpunkt des "Programmabsturzes" ansehen. 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 debugen. 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, Automatische einrückungen in Funktionen usw.) automatisch an die üblichen Standarts 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 Formatierungsarten aufgrund ihrer Gewöhnung als besser lesbar einschätzen, kann dies sehr nützlich sein.

Grundlegende Themen

C Fehler - Bugs - Probleme

Links