Fragen und Kommentare zur 7. Vorlesung / zum 7. Übungsblatt

@Martin: Das liegt einfach an der Art und Weise wie findMatches implementiert ist (ich gehe davon aus, dass Sie im Wesentlichen meine Implementierung aus der Vorlesung übernommen haben). Das fgets liest ja immer bis zum nächsten \n, es sei denn es kommt keins mehr, dann liest es bis zum Ende der Datei. Wenn jetzt die letzte Zeile mit einem \n endet, dann wird die gelesen, danach ist feof(inputFile) noch *nicht* true und für die Zeile wird das if (isMatch...) ... aufgerufen. Erst in der nächsten Iteration, wird mit fgets das Ende der Datei erreicht, und direkt danach wird dann die Schleife mit break' verlassen. Endet die letzte Zeile aber nicht mit einem \n, liest fgets bis zum Ende der Datei, danach ist feof(inputFile) == true und mit der nächsten Zeile wir die Schleife verlassen, noch bevor das if (isMatch...) ... verlassen wird. Man kann jetzt darüber streiten ob eine Zeile ohne ein \n am Ende eine Zeile ist. Sie können meinen Code abändern, so dass er auch mit diesem Spezialfall sinnvoll(er) umgeht, Sie den Code aber auch so lassen wie er ist. Generell ist eine Textdatei ohne newline am Ende immer schlechter Stil, und die meisten Editoren zeigen für solchen Dateien auch eine Warnung an, weil es einfach bei vielen Programmen zu Fehlern führt, aus ganz ähnlichen Gründen wie den genannten. Ok? Hannah 14Jun10 20:18

@TimV: Keine Ahnung ob Hudson geht, mein(e) Browser kann/können auch keine Verbindung aufbauen. Eine andere Frage: In dem TODO im Grepp.cpp steht, wenn die Zeile > MAX_LINE_LENGTH ist, soll eine Warnung ausgespuckt werden. Soll die Warnung in stderr geschrieben werden oder reicht ein printf("Warning...) aus? (BetimM 14Jun10 19:49)

Kann es sein, dass Hudson grad nicht geht? Habs mit Firefox und Opera probiert, aber beide sind der Meinung sie könnten keine Verbindung zum Server herstellen. Ist dem so, oder liegt der Fehler bei mir? (TimV 14Jun10 19:02)

Wieder mal ein merkwürdiger Fehler. Ich habe einen Test für die findMatches methode geschrieben, in der ich eine Textdatei mit drei Zeilen erzeuge. In der ersten und in der dritten Zeile befindet sich ein Schlüsselwort, was gefunden werden soll. Die Ausgabe des der Suche wird wiederum in einer Datei gespeichert, die ich dann auslese. Jetzt das merkwürdige: Wenn diese drei Zeilen alle einen Zeilenumbruch am Ende haben, funktioniert alles problemlos. Wenn ich aber bei der letzten Zeile den Zeilenumbruch weglasse - der ist ja unnötig, oder? - wird nur das erste auftreten des Patterns (also der in der ersten Zeile) gefunden und der Test geht schief, weil er beim einlesen der zweiten Zeile aus dem Suchergebnis - die ja eigentlich die dritte aus der Testfile sein sollte immer noch die erste lädt. Zusätzlich failed dann noch der Test unterhalb dieses Test, der aber gar nicht mehr in den geschweiften Klammern des ersten Tests ist. Also nochmal zum Verständnis: Wenn das Testfile schreibe ich so generiert wird:

  fprintf(testFile, "Here we have a pattern in the first line.\n");
  fprintf(testFile, "Nothing to be found in the second line.\n");
  fprintf(testFile, "Another pattern can be found in the third line.\n");

Here we have a pattern in the first line.
Another pattern can be found in the third line.

  fprintf(testFile, "Here we have a pattern in the first line.\n");
  fprintf(testFile, "Nothing to be found in the second line.\n");
  fprintf(testFile, "Another pattern can be found in the third line.");

myFile = fopen("filename", "a+");
while(true)
{
    char c;
    c = getchar();
    fprintf(myFile, "%c", c);  
}

@Hannah Verstehe ich das dann richtig, dass ein $ oder ein ^ im Pattern als wirkliches Zeichen interpretiert werden und nur am Anfang und Ende die besondere Bedeutung haben? Johannes 14Jun10 14:21

@Johannes: Also das war so gedacht. Wenn --regularExpressionMatch == false dann sind Hütchen und $ und . Zeichen wie jede andere, sowohl im Muster als auch im Text. Wenn -regularExpressionMatch == true dann haben Sie die beschriebene Sonderbedeutung im pattern, egal an welcher Stelle sie dort stehen, siehe mein vorheriger Kommentar dazu. Letzteres bedeutet, dass man dann ein Hütchen und ein $ im Text gar nicht exakt matchen kann (man müsste dann . im pattern schreiben, weil der matched ja alles). Hannah 14Jun10 13:59

Ich habe nochmal eine Frage, darf ein $ auch in einem Pattern vorkommen und wenn ja, was passiert dann? Also ich meine (Johannes 14Jun10 13:45)

asd$ ff$
oder
asd$ ff

@Johannes: Ojeoje, noch ein Fehler, ja, da habe ich _caseSensitiveMatch und _caseInsensitiveMatch durcheinander gebracht. Habe es jetzt alles mit Bezug auf _caseSensitiveMatch umgeschrieben und ins SVN gemacht, hoffentlich stimmt's jetzt. Wobei ja jeweils klar sein sollte, wie es gemeint ist. Hannah 14Jun10 12:17

Wie sollen wir eigentlich mit einem Pattern der Form

^^^^^^asdf$$$$$

umgehen - das funktioniert ganz normal, wenn die Zeile asdf lautet, oder? SebastianS 14Jun10 12:12

Ist in dem Kommentar nicht ein Fehler drin? Es müsste doch heißen with _caseInsensitiveMatch = True oder? (Johannes 14Jun10 11:05)

  // Of course, any combination of values for _caseSensitiveMatch and
  // _regularExpressionMatch should work. For example, with _caseSensitiveMatch
  // == true and _regularExpressionMatch == true, the following calls to isMatch
  // should return true:
  //   isMatch("This is just a line", "^THis")

  // If _regularExpressionMatch == true, the characters ^ and $ and . have a
  // special meaning.  Namely, the ^ matches only at the beginning of the line,
  // the $ matches only at the end of the line, and the . matches any character.

@Dario: Wenn man mit getopt.h und getopt bzw. getopt_long die Optionen parsed, wie in der Vorlesung vorgemacht, dann ist in der while(true) Schleife wann immer eine Option erkannt wurde optarg gerade das Argument dieser Option (falls es eine Option mit Argument war). Hannah 13Jun10 23:34

@Martin: So wie ich Fabian verstanden habe, ist sein Problem inzwischen gelöst (siehe sein Beitrag Fabian 13Jan10 17:08, erster Satz). Wenn das Ihr Problem nicht löst, was ist denn dann noch Ihr Problem? Hannah 13Jun10 23:31

@Simson: Wenn ^ in einem regulären Ausdruck nicht an erster Stelle vorkommt, bedeutet das mit Sicherheit keinen Treffer und so sollte sich isMatch dann auch verhalten (und idealerweise sollte es einen Test geben, der das nachprüft). Das selbe mit einem $, das nicht am Ende steht. Hannah 13Jun10 23:27

Hallo, kann jemand mir sagen was dies optarg z.B. _inputFileName = optarg; bedeutet? Dario 13Jun10 21:47

Ich habe das gleiche Problem wie Fabian 13Jun10 15:34. Was kann man da tun? MartinW 13Jun10 20:08

Soll man eigentlich irgendwie auf ^/& bei einem regulären Ausdruck reagieren, wenn diese nicht am Anfang/Ende stehen oder sollen die dann einfach als normales Zeichen verwendet werden? Simson 13Jun10 18:36

Problem hat sich erledigt - fclose(outputFile) muss an passender Stelle eingebunden werden!

@Tina: So wie ich das verstehe, hat das wirklich nur 3 Argumente, du könntest ebensogut ./GrepMain --input-file=<filename> xyz schreiben. Und an der Stelle, wo du argv[1] = const_cast<char*>("--input-file=???") brauchst, willst du ja den Dateinamen parsen - d.h. an der Stelle ist in _inputFileName eben noch nichts gespeichert. Das wird ja grade erst durch das parsen gemacht. An der Stelle im Test musst Du also erst von Hand ein Testfile anlegen, z.B. mit

FILE* testInputFile = NULL;
testInputFile = fopen("testfile.txt", "w");
fprintf("Testzeile 1\n");
   (...)
fclose(testInputFile);

This is line 1.
This is line 3 and the line is too long because it has too many characters: This

  FILE* outFile = NULL;
  outFile = fopen("testoutput", "r");
  if (outFile != NULL)
  {
    char* line = new char[MAX_LINE_LENGTH + 1];
    fgets(line, MAX_LINE_LENGTH + 1, outFile);
    printf("Line: %s\n", line);
    ASSERT_EQ('1', line[13]);
    fgets(line, MAX_LINE_LENGTH + 1, outFile);
  }

Line: ??,@??,@?
GrepTest.cpp:334: Failure
Value of: line[13]
  Actual: '?' (4, 0x4)
Expected: '1'
Which is: '1' (49, 0x31)

#include <stdio.h>

int MAX_LINE_LENGTH = 80;

int main()
{
  FILE* outFile = NULL;
  outFile = fopen("testoutput", "r");
  if (outFile != NULL)
  {
    char* line = new char[MAX_LINE_LENGTH + 1];
    fgets(line, MAX_LINE_LENGTH + 1, outFile);
    printf("Line: %s\n", line);
    fclose(outFile);
  }
}

@Dario: Sei meinen am Anfang in der Zeile CXX = g++ -Wall? Das -W steht einfach für warnings und -Wall heißt, dass der Compiler besonders pingelig sein und jede Warnung ausgeben soll. Bei früheren g++ Versionen hat das einen großen Unterschied gemacht, inzwischen ist aber die default Einstellung schon fast so pingelig wie -Wall. Was auch richtig ist, denn 99% aller Warnungen sind ein Hinweis auf Programmierfehler, gerade bei Programmieranfängern. Hannah 13Jun10 14:07

Was heißt die -Wall am Ende der Make file datei? Dario 13Jun10 13:14

@MartinW bez. Testen von findMatches und --input-file und --output-file. Erzeugen Sie in Ihrem Test eine einfache Eingabedatei, setzen Sie _inputFileName und _outputFileName, rufen Sie findMatches auf, lesen Sie die Ausgabedatei in einen String (mit fgets oder fread) und prüfen Sie dann ob der Inhalt dieser Datei der ist, der er sein sollte. Hannah 13Jun10 00:53

@fry: Danke für die Kommentare, stimmt beides genau. Wobei vielleicht noch ergänzen wäre, dass man fprintf auch genau verwenden kann wie printf, also mit Platzhalte wie %s oder %d in dem string und dann die entsprechenden Variablen als weitere Argumente. Hannah 13Jun10 00:47

@Martin: Wegen der MAX_LINE_LENGTH, ja genau, wenn Sie die auch in der GrepTest.cpp brauchen, müssen Sie sie in der Grep.h deklarieren. Das hatten wir ja auch glaube ich schon mal mit MAX_LIST_SIZE in der ListOfIntegers.h. Hannah 13Jun10 00:46

@Martin + Fabian + Alle: Ja, das muss natürlich -- heißen, habe das gerade im SVN korrigiert, danke für den Hinweis. Hannah 13Jun10 00:44

Gibt es eine Möglichkeit im Test auf die Konstante MAXIMUM_LINE_LENGTH zuzugreifen? Zum Beispiel in dem die Definition nicht in der Grep.cpp sondern bei den Membervariabeln in der Grep.h festgelegt wird? Ich muss die Konstante lesen können, um den Test für das Überschreiten der maximalen Zeilenlänge zu schreiben. MartinS 12Jun10 21:36

Da hat sich wohl jemand verschrieben. Auf dem Aufgabenblatt steht's mit "--" und ich tippe mal schwer drauf, dass das stimmt. Fabian 12Jun10 18:28

Wieso muss eigentlich -regular-expression-match nur mit einem - aufgerufen werden, während alle anderen mit zwei -- aufgerufen werden (laut usage info). Und wie sag ich das dann getopt? Martin 12Jun10 18:24

PS: Wenn man das Ding mit ShortOps aufrufen können will müssen die, die ein Argument brauchen ein hinter sich":". Beispiel "i" und "o" brauchen ein Argument:

static struct option options[] =
{
  {"input-file"              , 1, NULL, 'i'},
  {"case-insensitive-match"  , 0, NULL, 'c'},
  {"output-file"             , 1, NULL, 'o'},
  {"regular-expression-match", 0, NULL, 'r'},
  {NULL                      , 0, NULL,  0 }
};
optind  = 1;
int c = 0;
while ((c = getopt_long(argc, argv, "i:co:r", options, NULL)) != -1)

  fprintf(yourfile, "The string to be added")

@Hannah: Noch eine Frage zu Ihrer Musterlösung zum letzten Blatt: Ist die Musterlösung const-korrekt? Meiner Meinung nach müsste hinter find noch ein const, da ja nichts an dem Objekt verändert wird. Fabian 10Jun10 14:18

@Martin: Stimmt + super, dass Sie das rausgefunden haben, ein wirklicher gemeiner und schwer zu findender Bug, ich würde sagen das ist (mindestens) einen Bonuspunkt wert! Ich habe da beim Erklären nicht dran gedacht, weil man ja normalerweise die Kommandozeilen-Parameter nur einmal parsed. Aber bei mehreren Tests hintereinander halt öfter, und dann muss man optind in der Tat von Hand zurücksetzen. Ich habe das jetzt auch in der vorlesungen/vorlesung-7/Grep.cpp geändert und kommentiert, einfach svn update machen. Hannah 10Jun10 12:43

Habe den Fehler durch merkwürdige Fehlermeldungen von GTest gefunden. Ich hatte in GrepTest die drei Tests mit Optionen als den für das input file, output file und case insensitive match hintereinander. Zuerst war der Fehler beim output file test. Nachdem ich den mal auskommentiert hatte war er im case insensitive match test. Dann habe ich mal die Reihenfolge vertauscht. Der Fehler trat also immer in dem Test nach dem ersten Test mit Option auf. Dies ließ sich dann beheben indem ich die Variable "optind" vor der while Schleife auf 1 gesetzt habe. optind ist eine externe Variable von getopt die auf den Index des nächsten zu prozessierenden Eintrags im Feld argv zeigt. Diese wird vom System standardmäßig auf 1 gesetzt und läuft hoch, wenn die Optionen geparsed werden (siehe man 3 getopt). Wenn man jetzt den nächsten Test aufruft, steht diese Variable immer noch auf dem letzten Element des argv Zeigers. Das hießt c wird gleich auf -1 gesetzt und verlässt die Schleife und setzt auch _outputFileName nicht. Es ist also sinnvoll vor jedem Durchlauf der Parsingschleife optind auf 1 zu setzen. Eine Lösung wäre also:

  optind = 1;
  while (true)
  {
    int c = getopt_long(argc, argv, "ioc", options, NULL);
    if (c == -1) break;
    switch (c)
  ...

    argv[0] = const_cast<char*>("");
    argv[1] = const_cast<char*>("--output-file=out.txt");
    argv[2] = const_cast<char*>("P");

    int argc = 3;
    char* argv[3];
    argv[0] = const_cast<char*>("");
    argv[1] = const_cast<char*>("--output-file=out.txt");
    argv[2] = const_cast<char*>("P");

  // First parse the options.
  struct option options[] =
  {
    {"input-file"            , 1, NULL, 'i'},
    {"output-file"           , 1, NULL, 'o'},
    {"case-insensitive-match", 0, NULL, 'c'},
    {NULL                    , 0, NULL,  0 }
  };
  while (true)
  {
    int c = getopt_long(argc, argv, "ioc", options, NULL);
    if (c == -1) break;
    switch (c)
    {
      case 'i':
        _inputFileName = optarg;
        break;
      case 'c':
        _caseSensitiveMatch = false;
        break;
      case 'o':
        _outputFileName = optarg;
        break;
      default:
        printUsage();
        exit(1);
    }

    Grep grep;
    int argc = 4;
    char* argv[4];
    argv[0] = const_cast<char*>("");
    argv[1] = const_cast<char*>("--output-file");
    argv[2] = const_cast<char*>("out.txt");
    argv[3] = const_cast<char*>("P");
    grep.parseCommandLineArguments(argc, argv);
    ASSERT_EQ(0, grep._inputFileName[0]);
    ASSERT_EQ('P', grep._pattern[0]);
    ASSERT_EQ(0, grep._pattern[1]);
    ASSERT_EQ('o', grep._outputFileName[0]);
    ASSERT_EQ('u', grep._outputFileName[1]);
    ASSERT_EQ('t', grep._outputFileName[2]);
    ASSERT_EQ('.', grep._outputFileName[3]);
    ASSERT_EQ('t', grep._outputFileName[4]);
    ASSERT_EQ('x', grep._outputFileName[5]);
    ASSERT_EQ('t', grep._outputFileName[6]);

Value of: grep._outputFileName[0]
  Actual: '\0' (0, 0x0)
Expected: 'o'
Which is: 'o' (111, 0x6F)

@Simson: Indeed, da fehlt ein Punkt, danke für den Hinweis! Habe ihn jetzt gerade noch zugefügt und die neue Version committed. Machen Sie einfach svn update, dann bekommen Sie ihn auch Hannah 10Jun10 00:14

Sollte isMatch("This is just a line", "a..ne$") wirklich wahr zurückgeben? Fehlt da nicht ein . ? Simson 10Jun10 00:09