ich habe eine klasse. für diese klasse biete ich einen " operator<< " und einen " operator>> " an. ich möchte diese beiden funktionen gerne ausnahmesicher gestalten. beim ausgabe-operator ist es mir klar, wie ich das machen soll. beim lese-operator nicht so ganz. meine idee:
die position mit einer variable und mit std::basic_istream<>::tellg() speichern und im falle einer ausnahme mit std::basic_istream<>::seekg() wiederherstellen. ich bin mir nicht so sicher ob dies:
1. korrekt ist
2. auch in der praxis so gelöst wird

mich würde also eure meinung und eure eigenen ansätze dazu interessieren.

gruss.

ps.: was mir im bezug dazu auch aufgefallen ist, ist dass die input-operatoren für die nativen typen alle nur die grundlegende garantie (übersetzt man das so?) gewährleisten, so wie seekg() auch...

die position mit einer variable und mit std::basic_istream<>::tellg() speichern

.. bitte sag mir nicht, dass deine I/O-Operatoren Funktionstemplates sind.

Wieso Operatoren eigentlich ausnahme-sicher machen?

korrekt ist

Nicht immer.

auch in der praxis so gelöst wird

Ein klares Nein (zumindest nie i.A.).

die position mit einer variable und mit std::basic_istream<>::tellg() speichern

.. bitte sag mir nicht, dass deine I/O-Operatoren Funktionstemplates sind.

doch, das sage ich noch immer und du wirst mich noch immer darauf hinweisen, dass das overengineering ist.

Arcoth schrieb:

Wieso Operatoren eigentlich ausnahme-sicher machen?

gehen wir von einem fall aus, in welchem in einer datei viele dieser klassen gespeichert sind. nach 100'000 dieser klassen wirft einer dieser " operator>> "-en eine exception. mit der grundlegenden garantie ist ansich nicht versichert, dass ich danach an der selben stelle weiterlesen kann (so wie ich die grundlegende garantie verstanden habe ist nicht einmal garantiert das die selbe datei noch geöffnet ist).

link.

http://www.cplusplus.com/reference/istream/basic_istream/operator>>/ schrieb:

Basic guarantee: if an exception is thrown, the object is in a valid state.
It throws an exception of member type failure if the resulting error state flag is not goodbit and member exceptions was set to throw for that state.
Any exception thrown by an internal operation is caught and handled by the function, setting badbit. If badbit was set on the last call to exceptions, the function rethrows the caught exception.

ich interpretiere das so, dass ich von nichts ausgehen darf was nicht explizit beschrieben ist. ich darf also davon ausgehen, dass der stream in einem gültigen zustand ist. mehr nicht. auch nicht, dass er - wie zuvor - mit einer datei verknüpft ist und an einer bestimmten stelle liest.

Arcoth schrieb:

korrekt ist

Nicht immer.

was genau nicht (aus neugier, nicht dass ich dir nicht glauben würde)?

Arcoth schrieb:

auch in der praxis so gelöst wird

Ein klares Nein (zumindest nie i.A.).

willst du mit dem post andeuten, dass ich auf die exceptionsicherheit bei i-/o-operatoren verzichten soll und es keine ernstzunehmenden alternativen gibt?

seekg wird z.B. nicht funktionieren wenn der Stream mit der Konsole verbunden ist. Oder einem Socket, einer Pipe etc.

Und auf putback kann man sich auch nicht verlassen, da nicht garantiert ob bzw. wie oft putback funktionieren muss.

Wenn du nach einem Fehler weiterlesen können möchtest, dann wäre es vermutlich das Beste dich ausserhalb der Stream-Operatoren darum zu kümmern. Dort kannst du dann auch ganz einfach zwischen "Stream Extraction Fehler" und "seekg Fehler" unterscheiden.

Wobei mir der Sinn dahinter nicht ganz klar ist. Also: wozu willst du das haben?

Stream Extraction Operatoren werden üblicherweise nicht exception-safe gemacht, da es nicht möglich ist sie für alle Streams bzw. unter allen Umständen exceptions-safe zu machen.

seekg wird z.B. nicht funktionieren wenn der Stream mit der Konsole verbunden ist. Oder einem Socket, einer Pipe etc.

Und auf putback kann man sich auch nicht verlassen, da nicht garantiert ob bzw. wie oft putback funktionieren muss.

achso, ja. leuchtet ein.

hustbaer schrieb:

Wenn du nach einem Fehler weiterlesen können möchtest, dann wäre es vermutlich das Beste dich ausserhalb der Stream-Operatoren darum zu kümmern. Dort kannst du dann auch ganz einfach zwischen "Stream Extraction Fehler" und "seekg Fehler" unterscheiden.

Wobei mir der Sinn dahinter nicht ganz klar ist. Also: wozu willst du das haben?

mein bisheriger ansatz war es, den echten input-stream in " std::basic_istringstream "s aufzuteilen und von denen dann zu lesen. ich dachte, das ist eine unnötig umständliche version und wollte die aufgabe in den operator verschieben.

gut, dann ist das geklärt. danke.