Programmieren in C++

Transkript

1 Programmieren in C++ SS 2016 Vorlesung 7, Dienstag 7. Juni 2016 (Eingabe / Ausgabe, Optionen) und Rest von Vorlesung 6: Rückgabe von Argumenten Prof. Dr. Hannah Bast Lehrstuhl für Algorithmen und Datenstrukturen Institut für Informatik Universität Freiburg

2 Blick über die Vorlesung heute Organisatorisches Inhalt Erfahrungen mit dem Ü6 String Klasse Ein paar typische Fehler Heisenbugs, etc. Ein- und Ausgabe fopen, fgets, stdin, stdout Kommandozeilenoptionen getopt_long Testen von IO und Optionen ASSERT_DEATH Übungsblatt 7: Eine Funktion, die alle Zeilen in einer Datei umdreht und optional Palindrome erkennt 2

3 Erfahrungen mit dem Ü6 1/5 Zusammenfassung / Auszüge Für viele relativ gut und schnell machbar Gut, um Zeiger und Speicherallokation zu verstehen Bei vielen aber auch Probleme und "Heisenbugs" Fehler, die nur manchmal auftreten siehe Folie 5 Vorlesung etwas durcheinander diesmal viel hin und her; copy constructor wurde nicht ganz klar; nicht genug Zeit alle Sachen zu erklären (wegen exit bug) "Blatt nach 0 Uhr unschaffbar, vormittags ein Kinderspiel" "Zum ersten Mal durch unit test einen Fehler gefunden" 3

4 Erfahrungen mit dem Ü6 2/5 EM und Fußball Moderne Gladiatorenkämpfe / Brot und Spiele / Unterhaltung für's Volk um Aufstände zu verhindern Wer gewinnt? Nordkorea. Zumindest in den Übertragungen in Nordkorea Wenn die EM ähnlich politisch korrekt abläuft wie der ESC, dann gewinnt natürlich die Ukraine Curling hätte mehr Aufmerksamkeit verdient Drastischer Qualitätsabfall in der Frage: beim Ü5 noch zu Existenz und Sinn des Lebens und jetzt Fußball War bei einem Public Viewing und habe Schach gespielt 4

5 Erfahrungen mit dem Ü6 3/5 Heisenbugs nach der Heisenbergschen Unschärferelation Fehler, die nur manchmal auftreten zum Beispiel: Bei Ihnen lokal geht's, in Jenkins nicht Der Test schlägt fehl, aber das Programm geht trotzdem Beispiel 1: strlen aufrufen auf einer Zeichenkette (char*), die nicht von einer 0 terminiert wird Dann ist es Zufall, was am Ende der Zeichenkette steht; wenn es zufällig eine 0 ist, funktioniert es, sonst nicht Beispiel 2: außerhalb allozierten Speicherbereich schreiben Wenn da nichts für das Programm Relevantes überschrieben wird, funktioniert es, sonst crasht es irgendwo 5

6 Erfahrungen mit dem Ü6 4/5 delete auf NULL Zeiger Folgendes ist laut Standard erlaubt, und tut nichts delete NULL; delete[] NULL; Man sieht deshalb manchmal in Code: delete _ptr; _ptr = NULL; // Free previously allocated memory. // In case delete is called again. Das (_ptr = NULL) ist aber schlechter Stil! Guter Code sollte so geschrieben sein, dass allozierter Speicher nur genau einmal wieder freigegeben wird 6

7 Erfahrungen mit dem Ü6 5/5 Dieser Code gibt ein double free warum? 7 String::String(const char* s) { _chars = new char[ ]; } String::~String() { delete[] _chars; } void String::set(const String s) { _size = s._size; delete[] _chars; _chars = new char[_size + 1]; for (size_t i = 0; i <= _size; i++) _chars[i] = s._chars[i]; } String a("doof"); String b("bloed"); a.set(b); Der Aufruf von set ist "call by value" Es wird eine "shallow copy" von b gemacht Man hat dann zwei Objekte mit demselben Wert für _chars Mit const String& s alles in Ordnung

8 Ein- und Ausgabe 1/7 Beispielprogramm in C #include <stdio.h> FILE* file = fopen("doof", "r"); const int max = 1000; char line[max + 1]; fgets(line, max, file); if (feof(file)) { } fclose(file); // Open "doof" for reading. // Max. length of a line. // +1 for trailing null. // Read until next newline. // End of file reached // Close the file. 8 Achtung: man muss beim Lesen einer Zeile eine Obergrenze für die Anzahl der Zeichen angeben Damit nicht in nicht-allozierten Speicher geschrieben wird Sonst "buffer overflow error", wie er hinter vielen Sicherheitslücken in Software steckt

9 Ein- und Ausgabe 2/7 Beispielprogramm in C++ #include <iostream> std::ifstream file("doof"); std::string line; std::fgets(file, line); if (file.eof()) { } file.close(); // Open file for reading. // Max. length of a line. // Read until next newline. // End of file reached // Close the file. Sehr ähnlich zu dem C-Code, außer dass man keine Obergrenze für die Länge einer Zeile braucht Benötigt aber Templates und die STL (die C++ Standard Bibliothek), die kommen erst in V8 und V9 dran Von daher in der Vorlesung heute erstmal noch C-Style 9

10 Ein- und Ausgabe 3/7 Die wichtigsten C-Befehle im Überblick fopenöffnet eine Datei, liefert FILE* zurück fcloseschließt die Datei wieder feofsagt, ob wir schon am Ende der Datei sind fread liest eine gegeben Anzahl Bytes aus einer Datei fwriteschreibt eine gegebene Anzahl Bytes in eine Datei fprintfschreibt formatiert in eine Datei, analog zu printf fgetsliest die nächste Zeile aus einer Datei Details dazu wie üblich mit man, z.b. man 3 fopen 10

11 Ein- und Ausgabe 4/7 Ein paar Besonderheiten Wenn fopen fehlschlägt, wird NULL zurückgegeben Auf NULL testen, sonst seg fault beim fgets o.ä. FILE* file = fopen( ); if (file == NULL) { perror(" "); exit(1); } Das Ende der Datei wird behandelt wie ein eigenes Zeichen (EOF = end of file) Wenn man das letzte "richtige" Zeichen aus einer Datei gelesen hat, ist also man noch nicht am Ende der Datei Sondern erst nach dem nächsten Lesezugriff 11

12 Ein- und Ausgabe 5/7 Benutzereingabe / Bildschirmausgabe Das sind in der Unix/Linux Welt auch "Dateien"! Die "Datei" für Benutzereingabe heißt standard input fgets(line, max, stdin); // Read line from user input. Die "Datei" für Bildschirmausgabe heißt standard output fprintf(stdout, "Doof\n"); // Write to the console. Außerdem gibt es noch die Fehlerausgabe standard error fprintf(stderr, "Falsch\n"); // Write to standard error Geht per default auf den Bildschirm, umleiten in der bash geht zum Beispiel mit./inputoutputmain 2> error.log 12

13 Ein- und Ausgabe 6/7 Testen einer Methode mit Eingabedatei Variante 1: als Teil vom Test eine Testdatei erzeugen Dann am Ende vom Test wieder löschen (mit unlink) Variante 2: Testdatei von Hand schreiben Integraler Bestandteil vom Test = muss mit ins SVN Achtung: in jedem Fall soll die Testdatei klein sein Zur Erinnerung: Unit Tests sollen grundsätzlich nur auf kleinen Beispielen laufen und nur wenig Zeit benötigen 13

14 Ein- und Ausgabe 7/7 Namenskonventionen C vs. C++ In C++ verwenden wir CamelCase ClassName, methodname, variablename, In C verwenden wir lower_case file_name, max_length, Zum Beispiel bei den ganzen FILE* Funktionen In der C++ Standard-Bibliothek (STL) wird allerdings auch lower_case verwendet siehe Vorlesung 8 14

15 Parsen von Optionen 1/8 Beispiel mit "langen" Optionennamen Typischer Aufruf von der Kommandozeile./InputOutputMain --shift=3 --numbers doof.txt Zur Erinnerung: Argumente der main Funktion int main(int argc, char** argv); Die Werte von argv sehen dann so aus: argv[0] :./InputOutputMain argv[1] : --shift=3 argv[2]: --numbers argv[3] : doof.txt 15

16 Parsen von Optionen 2/8 Beispiel mit "kurzen" Optionennamen Äquivalenter Aufruf zu dem von der Folie vorher:./inputoutputmain -s 3 -n doof.txt Argumente der main Funktion int main(int argc, char** argv); Die Werte von argv sehen jetzt so aus: argv[0] :./InputOutputMain argv[1] : -s argv[2] : 3 argv[3]: -n argv[4] : doof.txt 16

17 Parsen von Optionen 3/8 Verarbeitung mit getopt, Teil 1/3 Zuerst definiert man eine Struktur, die sagt, welche Optionen es gibt und wie sie heißen (lang und kurz) #include <getopt.h> struct option options[] = { { "shift", 1, NULL, 's' }, // Option with 1 arg. { "numbers", 0, NULL, 'n' }, // Option with 0 args. { NULL, 0, NULL, 0 } // End of array. }; An der jeweils dritten Stelle kann man anstatt von NULL auch einen Zeiger auf eine Variable (Typ int*) übergeben Siehe "man 3 getopt" für die Semantik davon 17

18 Parsen von Optionen 4/8 Verarbeitung mit getopt, Teil 2/3 Jetzt kann man die Optionen verarbeiten: optind = 1; // Start with argv[1]. while (true) { // s and n = short names, the : means with argument. char c = getopt_long(argc, argv, "s:n", options, NULL); if (c == -1) break; // No more options. switch (c) { // c is the short name. case 's': shift = atoi(optarg); // Argument in optarg. break; case 'n': numbers = true; // Option without arg. } } 18

19 Parsen von Optionen 5/8 Verarbeitung mit getopt, Teil 3/3 Jetzt noch die Nicht-Options Argumente if (optind + 1!= argc) { printusageandexit(); } filename = argv[optind]; Achtung: optind zeigt nach der vorherigen Schleife auf das nächste Argument, das keine Option mehr ist Optionen am Ende von argv wurden dabei "nach vorne getauscht", d.h. die folgenden Aufrufe sind äquivalent./inputoutputmain --shift=3 --numbers doof.txt./inputoutputmain doof.txt --shift=3 --numbers 19

20 Parsen von Optionen 6/8 Zwei wichtige globale Variablen aus getopt.h optind ist der Index von dem Argument, das getopt_long als nächstes bearbeitet optind ist zwar mit 1 initialisiert, aber Achtung: beim Testen hat man die getopt_long Schleife evtl. mehrmals hintereinander, deswegen vorher immer optind = 1 setzen optarg ist das Argument der zuletzt verarbeiteten Option, sofern sie ein Argument hatte (sonst NULL) optarg ist immer vom Typ char*, braucht man einen anderen Typ, muss man selber im Code konvertieren 20

21 Parsen von Optionen 7/8 Testen ob ein Programm "abbricht" wenn es soll Zum Beispiel, wenn es nicht mit den richtigen Optionen aufgerufen wurden InputOutput io; ASSERT_DEATH(io.parseArgs(0, NULL), "Usage:.*"); Argument 1: Aufruf, der zum Programmabbruch führt Argument 2: regulärer Ausdruck für Fehlermeldung, die das Programm dann (korrekterweise) produzieren soll Achtung: Funktioniert nur für Fehlermeldungen, die nach stderr geschrieben werden, etwa so: fprintf(stderr, "Usage:./InputOutputMain...\n"); 21

22 Parsen von Optionen 8/8 Noch eine Besonderheit von ASSERT_DEATH Interne Realisierung ist recht kompliziert, es wird ein sogenannter fork verwendet Der Prozess wird in zwei Prozesse aufgespalten Das gibt potenziell Probleme, wenn das Programm threads verwendet, also Teile hat, die unabhängig voneinander nebeneinander her laufen Deshalb gtest versprechen, dass es keine Probleme gibt ::testing::flags_gtest_death_test_style = "threadsafe"; Sonst kommt bei Ausführung der Tests eine Warnung 22

23 Hinweise zum Ü7 1/3 Typkonvertierung Manche Typkonvertierungen finden automatisch statt bool flag = true; int x = flag; // Will get the value 1 (true = 1, false = 0). Manche muss man explizit selber machen: const char* filename = "doof.txt"; char** argv = new char*[2]; argv[1] = filename; argv[1] = const_cast<char*>(filename); // A // B A gibt Warnung "deprecated conversion to char*" B konvertiert explizit von const char* nach char* 23

24 Hinweise zum Ü7 2/3 Vergleich von zwei Strings im Unit Test Umständliche Variante: ASSERT_EQ('d', result._chars[0]); ASSERT_EQ('o', result._chars[1]); ASSERT_EQ('o', result._chars[2]); ASSERT_EQ('f', result._chars[3]); ASSERT_EQ(0, result._chars[4]); Dasselbe in einer Zeile: ASSERT_STREQ("doof", result._chars); Geht aber nur bei 0-terminierten Zeichenketten! 24

25 Hinweise zum Ü7 3/3 Füttern einer Datei als Standardeingabe Um eine Datei als Standardeingabe für ein Programm zu nutzen, kann man Folgendes schreiben./inputoutputmain < doof.txt Alternativ geht auch: cat doof.txt./inputoutputmain Um die Standardausgabe in eine Datei umzulenken:./inputoutputmain > bloed.txt Um sowohl stdout und stderr umzulenken (bash):./inputoutputmain 2>&1 > bloed.txt 25

26 Literatur / Links C-style input / output man 3 fopen Dito für fgets, fprintf, feof, fread, fwrite, fclose, Parsen von Optionen man 3 getopt ASSERT_DEATH AdvancedGuide.md Abschnitt "Death Tests" const_cast 26