Gibt es hier elegantere Möglichkeiten - wie zB SmartPointer für die Verwaltung von Heapspeicher? Oder schliesst die ifstream/ofstream-Klasse einen geöffneten stream automatisch mittels Dtor nach Verlassen des Scopes?

Danke für eure Hilfe!

bool parse_file(const std::string& filename) {
  assert(!filename.empty());

  // Open ifstream
  std::ifstream ifs(filename.c_str());
  if (ifs.fail()) {
    errors << now << "Cannot find or open file: " << filename << "\n";
    return false;  // Exit with failure
  }

  std::cout << now << "Parsing file: " << filename << "\n";

  std::string input;
  boost::match_results<std::string::const_iterator> what;

  // Parse ifstream
  for (int line = 1; !getline(ifs, input, '\n').eof(); ++line) {
    // Trim leading and trailing whitespaces
    boost::algorithm::trim(input);

    // Continue if empty line
    if (input.empty()) continue;

    // Find a match with...
    if (!boost::regex_match(input, what, expression)) {
      errors << now << "Error abc: " << filename << " (" << line << ")\n";
      ifs.close();
      return false;  // Exit with failure
    }

    // Verify condition...
    if (...) {
      errors << now << "Error cde: " << filename << " (" << line << ")\n";
      ifs.close();
      return false;  // Exit with failure
    }

    // More tests do be done...
  }

  // Close ifstream
  ifs.close();
  return true;  // Exit with success
}

Oder schliesst die istream/ostream-Klasse einen geöffneten stream automatisch mittels Dtor nach Verlassen des Scopes?

Ja, wobei du dann nicht weißt, ob das schließen erfolgreich war, aber das scheint dich im Code sowieso nicht zu interessieren.

bool parse_file(const std::string& filename)
{
    using std::ifstream;
    ifstream reader;
    //Funktion soll Exception werfen, wenn Stream nicht okay
    //(parsing Fehler sind sind zu erwarten und sollen keine Exception werfen)
    reader.exceptions ( ifstream::badbit );
    reader.open(filename.c_str());

    std::string line;
    //lesen solange was da is
    while(std::getline(reader, line, '\n'))
    {
        //hier machen, was notwendig ist...
    }
    return true;
    //stream-Objekt wird automatisch geschlossen und zerstoert
}

Dabei werden Fehler im ifstream über eine Exception gemeldet. Ein fehlgeschlagenes Parsing wird weiterhin über den Rückgabewert abgebacken.

Ja, wobei du dann nicht weißt, ob das schließen erfolgreich war, aber das scheint dich im Code sowieso nicht zu interessieren.

Wie prüfst du bei einem Aufruf von close() , ob das Schliessen erfolgreich war?

Tachyon schrieb:

So vielleicht?

Aber Fehler beim Schliessen erfährst du so auch nicht, sondern nur wenn der Stream während der Benutzung kaputt geht. Es wäre fatal, wenn der Destruktor von std::ifstream eine Exception werfen würde.

Tachyon schrieb:

So vielleicht?

Aber Fehler beim Schliessen erfährst du so auch nicht, sondern nur wenn der Stream während der Benutzung kaputt geht. Es wäre fatal, wenn der Destruktor von std::ifstream eine Exception werfen würde.

Schließen interessiert eigentlich auch nicht. Ansonsten kann man tatsächlich explizit close() aufrufen und auf badbit prüfen. Das kann für close() aber eigentlich nur gesetzt werden, wenn man keine Datei geöffnet hat (wenn das Öffnen schief geht, ist badbit eh schon gesetzt).
PS: Man kann auch das close vom unterliegenden filebuf aufrufen, und den Rückgabewert prüfen.

Nexus schrieb:

Tachyon schrieb:

So vielleicht?

Aber Fehler beim Schliessen erfährst du so auch nicht, sondern nur wenn der Stream während der Benutzung kaputt geht. Es wäre fatal, wenn der Destruktor von std::ifstream eine Exception werfen würde.

Schließen interessiert eigentlich auch nicht. Ansonsten kann man tatsächlich explizit close() aufrufen und auf badbit prüfen. Das kann für close() aber eigentlich nur gesetzt werden, wenn man keine Datei geöffnet hat (wenn das Öffnen schief geht, ist badbit eh schon gesetzt).

Closes the file currently associated with the object, disassociating it from the stream. Any pending output sequence is written to the physical file.

Ich würde mal sagen, dabei kann noch mehr schief gehen.

Closes the file currently associated with the object, disassociating it from the stream. Any pending output sequence is written to the physical file.

Ich würde mal sagen, dabei kann noch mehr schief gehen.

Noch mehr als wobei? Das einem close implizit ein flush voraus geht, sollte ja wohl klar sein.

Noch mehr als wobei?

Mehr als das was du schreibst.

Tachyon schrieb:

Ansonsten kann man tatsächlich explizit close() aufrufen und auf badbit prüfen. Das kann für close() aber eigentlich nur gesetzt werden, wenn man keine Datei geöffnet hat (wenn das Öffnen schief geht, ist badbit eh schon gesetzt).

Das ... badbit ... kann für close() aber eigentlich nur gesetzt werden, wenn man keine Datei geöffnet hat

Das:

Das ... badbit ... kann für close() aber eigentlich nur gesetzt werden, wenn man keine Datei geöffnet hat

Tja, in der Theorie wäre es schön, wenn es so wäre, dass auch bei Speichermangel badbit gesetzt wird. Leider definiert des Standard das nicht. Das einzige definierte Fehlerverhalten, ist das oben von mir beschriebene.

Tja, in der Theorie wäre es schön, wenn es so wäre, dass auch bei Speichermangel badbit gesetzt wird. Leider definiert des Standard das nicht. Das einzige definierte Fehlerverhalten, ist das oben von mir beschriebene.

Dann ist ja ofstream für alles sicherheitsrelevante völlig ungeeignet, wenn man nicht mal prüfen kann, ob irgendwas auf Platte geschreiben wurde.

Dann ist ja ofstream für alles sicherheitsrelevante völlig ungeeignet, wenn man nicht mal prüfen kann, ob irgendwas auf Platte geschreiben wurde.

Tja, nichts ist jemals einfach...

Wird das mit dem neuen Standard verbessert?

Hmm, ich glaube, ich habe mal wieder Müll erzählt, zumindest zum Teil. Auf gängigen Plattformen dürfte das intern (in std::filebuf) benutzt std::fclose einen Fehler erzeugen, wenn irgendwas schief geht (kein Platz, Datei inzwischen gelöscht, etc.).

Allerdings ist das Verhalten implemntierungsabhängig, weil ja der Filedeskriptor aus allen möglichen Quellen kommen kann und auf allen möglichen Plattformen funktionieren ssoll, und bestimmte Fehler gar nicht auftreten können. Man kann also gar kein eindeutiges Fehlerverhalten definieren.

Auf gängigen Plattformen sollte z.B. auch ein fstream::close() zum Setzten von badbit führen, wenn z.B. kein freier Speicher zum Schreiben des Restpuffers da ist.
Das Problem ist eben, dass man sich nicht darauf verlassen kann. Nur das am Anfang beschriebene Verhalten ist klar definiert.

Andere Anwendungen können z.B. die selbe Datei gleichzeitig öffnen (vielleicht unter Windows nicht, aber mit dem native API dann wahrscheinlich doch), dann kann es passieren dass man 10 Bytes schreibt und die Datei plötzlich 20 Bytes lang ist. Das Filehandle kann dir unterm Schreiben vom OS entzogen werden (probier mal chkdsk /F /V aus). Im Prinzip kann auch das OS zurückmelden, dass die Bytes geschrieben wurden, und dann plötzlich abrauchen ohne dass es wirklich auf der Disk steht. Nicht mal sowas wie FileExists(path) == FileExists(path) ist zwangsläufig immer true, weil es zu race conditions kommen kann.

Ohne spezielle Hilfe und Garantien vom OS sind Dateioperationen nicht verlässlich, und es gibt meiner Meinung nach nichts, was fstream dagegen tun kann. Dafür ist es einfach zu systemfern. Das heißt aber nicht, dass es unbrauchbar, man sollte halt nur kein Datenbanksystem damit programmieren.