1
2
3

, wobei nach dem dreier nichts mehr kommt (keine whitespaces, insbesondere kein new line)

und ich den Inhalt einlese mit:

ifstream ifs("filename.txt");
while(ifs.good()) {
		getline(ifs, line);

		cout << line << endl;
	}

, dann iteriert er einmal zu oft drüber (also 4 mal). wodruch noch eine leerzeile am schluss ausgegeben wird.
.good() müsste doch eigentlich das eofbit checken und wenn es gesetzt ist, dann müsste False zurückgegeben werden, wodurch die Schleife eigentlich nur drei mal durchlaufen werden müsste.

Weiß jemand Rat?

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.

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.

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.

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.

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.

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?

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.

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...

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.