Schleife mit .good() iteriert zu oft

Cloudwalker

cool danke, es funktioniert tatsächlich mit

while(getline(ifs, line)) {        
        cout << line << endl;
    }

Es müsste dann irgendwie so sein, dass die getline Methode beim Einlesen von "3" noch nicht checkt, dass dies die letzte Zeile ist und das eof-bit noch nicht setzt, sondern erst beim nächsten leseversuch merkt, dass es nichts mehr zum lesen gibt denke ich.

Athar

Cloudwalker schrieb:

Es müsste dann irgendwie so sein, dass die getline Methode beim Einlesen von "3" noch nicht checkt, dass dies die letzte Zeile ist und das eof-bit noch nicht setzt, sondern erst beim nächsten leseversuch merkt, dass es nichts mehr zum lesen gibt denke ich.

Wie schon gesagt, bei einem Stream weiß man in der Regel vorher nicht, wann er zu Ende ist.
Wenn ein Stream immer dann als "beendet" angesehen würde, wenn gerade keine Daten mehr zu lesen da sind, könnten wir uns jetzt nicht über's Internet unterhalten.

Athar schrieb:

Wie schon gesagt, bei einem Stream weiß man in der Regel vorher nicht, wann er zu Ende ist.
Wenn ein Stream immer dann als "beendet" angesehen würde, wenn gerade keine Daten mehr zu lesen da sind, könnten wir uns jetzt nicht über's Internet unterhalten.

Wie schon gesagt, wie das Quatsch. Mit einem while( getline.. ) könnten wir uns jetzt auch nicht über's Internet unterhalten.

MFK

elfN schrieb:

Wie schon gesagt, wie das Quatsch. Mit einem while( getline.. ) könnten wir uns jetzt auch nicht über's Internet unterhalten.

Ich glaube, du hast das immer noch nicht verstanden. Argumentierst du immer noch mit diesem "Lesezeiger"? Ist dir klar, dass es so etwas im allgemeinen Fall gar nicht gibt? Streams gibt's nicht nur für Dateien.

MFK schrieb:

elfN schrieb:

Wie schon gesagt, wie das Quatsch. Mit einem while( getline.. ) könnten wir uns jetzt auch nicht über's Internet unterhalten.

Ich glaube, du hast das immer noch nicht verstanden. Argumentierst du immer noch mit diesem "Lesezeiger"? Ist dir klar, dass es so etwas im allgemeinen Fall gar nicht gibt? Streams gibt's nicht nur für Dateien.

Das ist völlig egal. Du kannst ein Flag "EOF" auf true setzen, wenn du versuchst was zu lesen und am Ende bist oder eine Funktion schreiben, die prüft, ob es was zu lesen gibt und true oder false liefert. Da ist es egal, was das für ein stream ist. Immer wenn du das Flag beim Lesen setzen kannst, kannst du auch direkt abfragen ob das Flag jetzt gesetzt würde, wenn du lesen würdest.

MFK

elfN schrieb:

Immer wenn du das Flag beim Lesen setzen kannst, kannst du auch direkt abfragen ob das Flag jetzt gesetzt würde, wenn du lesen würdest.

Darum geht's doch gar nicht.

Es geht darum, ob dieses Flag nach dem letzten erfolgreichen Lesevorgang gesetzt werden soll, oder nach dem ersten fehlgeschlagenen.

Wenn ich dich richtig verstanden habe, scheinst du Ersteres zu befürworten. Die C++-Streams tun aber Letzteres.

Der Grund dafür ist, dass du einem erfolgreichen Lesevorgang gar nicht zweifelsfrei ansehen kannst, ob er der letzte ist. Du weißt ja nicht, wann der nächste Lesevorgang erfolgt, und ob der Stream bis dahin nicht wieder Daten liefern kann. Warum also möglicherweise vorzeitig abbrechen?

MFK schrieb:

elfN schrieb:

Immer wenn du das Flag beim Lesen setzen kannst, kannst du auch direkt abfragen ob das Flag jetzt gesetzt würde, wenn du lesen würdest.

Darum geht's doch gar nicht.

Es geht darum, ob dieses Flag nach dem letzten erfolgreichen Lesevorgang gesetzt werden soll, oder nach dem ersten fehlgeschlagenen.

Wenn ich dich richtig verstanden habe, scheinst du Ersteres zu befürworten.

Nein. Ich bin für drittens: Gar kein EOF Flag setzen, sondern das machen was du meinst, worum es nicht geht, einfach eine direkte Abfrage.

MFK

elfN schrieb:

Ich bin für drittens: Gar kein EOF Flag setzen, sondern das machen was du meinst, worum es nicht geht, einfach eine direkte Abfrage.

Wie soll das in der Anwendung aussehen?

Gar kein EOF Flag setzen, sondern das machen was du meinst, worum es nicht geht, einfach eine direkte Abfrage.

Könntest du das bitte nochmal so formulieren, dass man es versteht? Besonders den Teil ab dem zweiten Komma verstehe ich nicht...

Wenn ich das richtig verstehe, meint er, dass eof() nicht nur ein Flag prüfen soll, sondern nachkucken, ob aus dem Stream noch etwas gelesen werden kann.

MFK hat im Grunde schon genannt, warum das eine alberne Idee ist. Wenn du an einer FIFO hängst, wird es schon schwierig, dafür eine sinnvolle Semantik zu definieren. Hängst du gar an einem benutzerdefinierten Stream, der seine Daten aus einer Berechnung zieht, kann es schnell völlig unmöglich werden.

Es macht aus meiner Sicht keinen Sinn, von einem Eingabestrom zu verlangen, dass er vor einem Leseversuch zu wissen habe, ob dieser funktionieren werde, zumal historisch unter iostreams liegende Betriebssystemsschnittstellen ein solches Verhalten nicht bieten. Man würde sich damit die Nutzung des Konzepts für solche Fälle versperren, in denen das nicht möglich oder nicht sinnvoll ist, ohne einen angemessenen Nutzen aus der Einschränkung zu ziehen.

Ich verstehe auch nicht, was der Aufruhr soll. Der übliche Anwendungsfall ist eh "Lies so lange Daten, wie du kannst" - die gesetzten Flags lassen sich später immer noch prüfen - und wenn man tatsächlich nur auf das eof-Bit prüfen will, schreibt man halt

while(getline(stream, str).eof()) {
  // ...
}

...wobei man sich dann natürlich um die Behandlung anderer Fehlerflags in der Schleife selbst kümmern muss.