A
Dravere schrieb:
Das ist aber kein Verstoss gegen das Liskovsche Substitutionsprinzip. LSP geht genau in die andere Richtung. Es müssen alle beweisbaren Eigenschaft der Basisklasse auch für die abgeleitete Klasse gelten. Das ist auch der Fall.
Das ist, technisch gesehen, deshalb kein Verstoß, weil die Basisklasse bereits die Möglichkeit, aus Gründen mangelnder Streamintegrität eine IO-Operation fehlschlagen zu lassen, einräumt. Jedoch: ist die Nichtexistenz eines Streams infolge einer Benutzeraktion dasselbe wie mangelnde Streamintegrität? Anders gesagt, du kannst das Objekt in einen Zustand versetzen, der im Interface der Basisklasse gar nicht vorgesehen ist. Um dieses Designproblem - die logische Verletzung des LSP - zu umgehen, wurde eben festgesetzt, daß nach dem Schließen eines Streams alle weiteren Operationen das bad-Flag setzen, zu dem die Dokumentation schreibt:
[
C++.com schrieb:
This flag is set by standard input operations when an error that caused the loss of integrity of the stream happened.
](http://www.cplusplus.com/reference/iostream/ios/bad/)
fstream führt nun eben eine Funktion ein, um diesen Zustand explizit herbeizuführen, und das aus einem Grund, der damit eigentlich gar nichts zu tun hat. Besser gewesen wäre, ein neues Flag wie "available" einzuführen, das diesen speziellen Zustand signalisiert - wofür man natürlich unschönerweise das Interface hätte verändern müssen. Aber noch viel besser wäre es gewesen, wenn man diese furchtbare Idee mit den Fehlerzuständen gar nicht erst umgesetzt hätte.
Dravere schrieb:
2. Nachher ist man immer klüger
Damit hast du, denke ich, das meiste, was zu den C++-Streams zu sagen wäre, auf den Punkt gebracht.
Dravere schrieb:
Ich persönlich habe ein wenig das Gefühl, dass du aus einer Mücke einen Elefanten machst und dich dann darüber beschwerst, dass du den Elefanten nicht hochheben kannst
Ich wünschte, es wäre so. Für den Vergleich mit einer Mücke sind die C++-Streams leider viel zu prävalent
