Mehrere Instanzen einer Klasse abspeichern

SeppJ

Das ist ein guter Anfang, ja. Vermutlich willst du aber noch irgendeine Art von Formatierung schreiben, damit du bei komplizierteren Datentypen (wie z.B. std::string oder eben auch deiner eigenen Klasse) sicher gehen kannst, dass das Einlesen auch wirklich die Umkehrung des Schreibens ist. Zum Beispiel ist

std::string foo = "Hallo Welt";
datei_raus << foo;

// ...

datei_rein >> foo;  // Nur "Hallo"

sulky

Ja genau, mit diesem Problem bin ich bereits konfrontiert.
Wie macht man das?

aber das noch viel grössere Problem ist folgendes:
Wenn ich die Klasse element erweitere um:

element*next;

so kann ich in der einschreibefunktion noch schreiben:

os<<e.a<<e.s<<e.next;

aber in der ausgabefunktion folgt eine Fehlermeldung auf

is>>e.a>>e.s;>>e.next;

wieso das?

Sone

reinterpreter schrieb:

Einerseits können chars und ints unterschiedlich gross sein, andererseits kann das Padding variieren. Zumindest kommen mir diese beiden in den Sinn, gibt vielleicht noch mehr Gründe. Was meinst du mit Offset?

Na den Member-Offset. Die Anzahl Bytes, die ein Member von seiner Instanz im Speicher entfernt liegt.

xff65464e Instanz
xff65464e Erster Member
0ff654653 Zweiter Member
:::

Ja, die Skalare können unterschiedliche Größen haben; das stimmt.

Sone

Ja genau, mit diesem Problem bin ich bereits konfrontiert.
Wie macht man das?

Größe mit serialisieren.
Also zuerst Größe reinschreiben und dann den String. Anschließend zuerst die Größe auslesen und dementsprechend lesen.

Bitte ein Bit

@Sone:
Sorry aber deine Lösung ist für mich ein Hack. Wer garantiert dass das Format sauber dokumentiert wird, s.d. in 5 Jahren, wenn jemand den Code wieder anfasst, das Datenformat auch ohne Probleme versteht.

Was spricht dagegen in solchen Fällen die Klassendefinitionen ins XML Format zu wandeln. Ist lesbarer als deine Lösung und eindeutiger definiert.

class ABC
{
public:
  std::string Name;
  std::string NachName
};

wird zu

<abc name="Hallo" NachName="Welt"/>

Kellerautomat

Vermutlich spricht gegen XMl, dass XML kacke ist. Sones Loesung ist, auch wenn ich es ungern zugebe, ausnahmsweise mal korrekt und imo die beste Loesung.

Hallo sulky ,
wieso hast du bis jetzt noch nich die Definition der Klasse gezeigt? Dann wüssten wir, um wie viele Attribute und um welche Datentypen es sich handelt. Dann ließe sich dir auch besser helfen.

Bitte ein Bit

Vermutlich spricht gegen XMl, dass XML kacke ist.

Warum ?

sulky schrieb:

aber das noch viel grössere Problem ist folgendes:
Wenn ich die Klasse element erweitere um:
element*next;
so kann ich in der einschreibefunktion noch schreiben:
os<<e.a<<e.s<<e.next;
aber in der ausgabefunktion folgt eine Fehlermeldung auf
is>>e.a>>e.s;>>e.next;
wieso das?

Du kannst nicht erwarten, dass Du den Zeiger einfach wegschreiben kannst, danach wieder einliest und der immer noch auf was sinnvolles zeigt.
Schreib den Zeiger nicht, lies den Zeiger nicht, sondern bau Deine Datenstruktur beim lesen wieder neu auf.

Marc++us

Ich erlaube mir das hier als Lektüre:

http://www.c-plusplus.net/forum/239586

Und zwar der Link auf "Kapitel 24: Wie man Zeiger in Dateien speichert".

Das spricht das Thema teilweise an.

Kellerautomat

Bitte ein Bit schrieb:

Vermutlich spricht gegen XMl, dass XML kacke ist.

Warum ?

- Unleserlich
- Kompliziert/aufwaendig
- Kompletter Overkill bei 99% der Anwendungen, die ich bisher gesehen habe.

... davon abgesehen sind Binaerformate grundsaetzlich besser.

SeppJ

Kellerautomat schrieb:

... davon abgesehen sind Binaerformate grundsaetzlich besser.

- Unleserlich
- Kompliziert/aufwaendig
- Kompletter Overkill bei 99% der Anwendungen, die ich bisher gesehen habe.

Kellerautomat

SeppJ schrieb:

- Unleserlich

Noe, gar nicht lesbar. Das war aber auch gar nicht die Anforderung. Lieber ein gar nicht lesbares Binaerformat, als ein unleserliches Textformat.

SeppJ schrieb:

- Kompliziert/aufwaendig

Noe. Das Parsen/Generieren von lesbarem Text entfaellt voellig. Man muss sich nicht mit laestigen Zeichenkodierungen herumschlagen. Oder Escape-Sequenzen.

SeppJ schrieb:

- Kompletter Overkill bei 99% der Anwendungen, die ich bisher gesehen habe.

Dann lass die Dateien am besten gleich bleiben.

SeppJ

Kellerautomat schrieb:

SeppJ schrieb:

- Unleserlich

Noe, gar nicht lesbar. Das war aber auch gar nicht die Anforderung.

Aber es war dein Kritikpunkt an XML. Bei Binärformat ist dieser Nachteil nochmals unendlich viel schlimmer ausgeprägt

SeppJ schrieb:

- Kompliziert/aufwaendig

Noe. Das Parsen/Generieren von lesbarem Text entfaellt voellig. Man muss sich nicht mit laestigen Zeichenkodierungen herumschlagen.

Dann zeig mal wie du einen std::string binär abspeicherst.

SeppJ schrieb:

- Kompletter Overkill bei 99% der Anwendungen, die ich bisher gesehen habe.

Dann lass die Dateien am besten gleich bleiben.

Wo ist der Vorteil des Binärformates? Größe der Datei, eventuell leicht höhere Parse-Geschwindigkeit. Bei welcher Anwendung ist dies wichtig? Falls Größe kritisch ist, zippt man die Datei eben noch. Wenn Geschwindigkeit beim Parsen wichtig ist, dann macht man wahrscheinlich etwas falsch.

Dafür hat das Binärformat aber ähnlich Komplikationen (Kritikpunkt 2) und den dicken Nachteil, gar nicht lesbar/editierbar zu sein. Man sollte seinen Einsatz daher schon sehr gut Begründen und es sollte nicht der Normalfall sein.

Kellerautomat

SeppJ schrieb:

Aber es war dein Kritikpunkt an XML. Bei Binärformat ist dieser Nachteil nochmals unendlich viel schlimmer ausgeprägt

Also ich finde ein struct in meiner Anwendung, in das diese Daten Member fuer Member hineingelesen werden, wesentlich lesbarer.

SeppJ schrieb:

Dann zeig mal wie du einen std::string binär abspeicherst.

Ein std::string weiss nichts von Zeichenkodierungen.

SeppJ schrieb:

Wo ist der Vorteil des Binärformates? Größe der Datei, eventuell leicht höhere Parse-Geschwindigkeit. Bei welcher Anwendung ist dies wichtig? Falls Größe kritisch ist, zippt man die Datei eben noch. Wenn Geschwindigkeit beim Parsen wichtig ist, dann macht man wahrscheinlich etwas falsch.

Ein Binaerformat ist viel leichter zu implementieren und benoetigt keine Fremdlibs.

SeppJ

Kellerautomat schrieb:

SeppJ schrieb:

Aber es war dein Kritikpunkt an XML. Bei Binärformat ist dieser Nachteil nochmals unendlich viel schlimmer ausgeprägt

Also ich finde ein struct in meiner Anwendung, in das diese Daten Member fuer Member hineingelesen werden, wesentlich lesbarer.

Lesbarer als welche Alternative? Alle vernünftigen Formate machen das so. Außerdem meine ich die Lesbarkeit des Formates. Meintest du etwa bisher den Code?

SeppJ schrieb:

Dann zeig mal wie du einen std::string binär abspeicherst.

Ein std::string weiss nichts von Zeichenkodierungen.

Zeig mal wie du ihn binär speicherst. Los.

Im übrigen sind Binärformate codegewordene Portabilitätsprobleme. Ziechencodierungen sind ein lächerlich geringes Problem gegen die Probleme, die du beim portieren von naiv geschriebenen Binärdaten bekommst. Und wenn du sie nicht naiv schreibst, hast du wieder eine komplexe Formatierungsaufgabe. Wieso dann die Nachteile des Binärformates in Kauf nehmen, wenn man auch gleich ein lesbares Format haben könnte.

SeppJ schrieb:

Wo ist der Vorteil des Binärformates? Größe der Datei, eventuell leicht höhere Parse-Geschwindigkeit. Bei welcher Anwendung ist dies wichtig? Falls Größe kritisch ist, zippt man die Datei eben noch. Wenn Geschwindigkeit beim Parsen wichtig ist, dann macht man wahrscheinlich etwas falsch.

Ein Binaerformat ist viel leichter zu implementieren und benoetigt keine Fremdlibs.

Welche Fremdlibs brauchst du für ein lesbares Format? Zeig mal eine Implementierung für dein Binärformat, welche nicht die von dir dem lesbaren Format zugeschriebenen Mängel hat.

P.S.: Irgendwie entsteht bei mir der Eindruck, dass du mir absichtlich das Wort im Mund verdrehst, weil du kein Unrecht eingestehen willst. Falls ich dir da Unrecht tue: Du solltest besser aufpassen, was du wie formulierst. Falls ich dies richtig erkannt habe:

hustbaer

@Kellerautomat
XML ist weder kompliziert noch unleserlich, und Binärformate sind in den meisten Fällen keine sinnvolle Alternative.
Binärformate sind schlecht erweiterbar, daher schlecht wartbar und grundsätzlich total unleserlich.

Das einzige was mMn. gegen XML spricht ist dass XML in C++ etwas fummelig zu verwenden ist.

Braunstein

Mich nervt bei XML besonders der Overhead. Das bläht eine ansonsten recht kleine Datei doch sehr auf.

SeppJ

Braunstein schrieb:

Mich nervt bei XML besonders der Overhead. Das bläht eine ansonsten recht kleine Datei doch sehr auf.

Man muss ja auch nicht zwangsläufig gleich zu XML greifen. Bei sehr vielen Anwendungen reichen Formate wie "Alle Zahlen nacheinander", "Ein String pro Zeile" oder auch das gute alte CSV. Hier im Thread ist das Problem, dass uns fast überhaupt gar nichts über die Daten und die Anwendung bekannt ist, das läuft dann bei den Antworten eben auf allerallgemeinste Formate hinaus.

sulky schrieb:

aber in der ausgabefunktion folgt eine Fehlermeldung auf
is>>e.a>>e.s;>>e.next;
wieso das?

Wie soll dir jemand die Frage beantworten, wenn du noch nicht einmal die Fehlermeldung nennst und wann du sie bekommst?
Im Zweifelsfall hast du die Zeile tatsächlich so geschrieben und ein ; zuviel.