Objekte speichern sich selber oder werden gespeichert?
-
DEvent schrieb:
Eine andere Möglichkeit in C++ wäre es, eine Klasse einfach den Operator << und >> anzubieten. << heist ja "schreibe in Stream" und >> heist "lese aus Stream".
Dann braucht man nur noch...vielleicht noch den typ davorschreiben vor die objekte und beim lesen anhand des type den richtigen ctor aufrufen.
und mit den zeigern kanns böse enden. soll man die verfolgen? wenn nein, hat man beim reinladen nen zeiger ins nirvana. wenn ja, sollte man doppelverfolgungen und muß kreise verhindern.
-
rüdiger schrieb:
Wer die Funktion nicht versteht, hätte kein Programmierer werden sollen. Wobei die Überladung wirklich ein wenig sinnlos ist in dem Fall.
Der Operator macht in diesem Fall einfach keinen Sinn, da man & einfach nicht mit serialisieren in Verbindung bringt, wenn man es nicht weiß. Das hat nichts mit Unwissenheit des Programmierers zu tun. Aber ein derartiger "Fehler" ist in diesem Fall natürlich erlaubt, weil es um boost geht ..
rüdiger schrieb:
Bietet eben den Vorteil, dass man je nach Datentechnologie eine andere Form der Persistenz wählen kann (z.B: wird man kaum in eine Datenbank serialisieren, sondern eher auf Tabellen abbilden).
Bietet den Vorteil gegenüber welcher Lösung?
Persistenz ist übrigens mehr als Serialisierung
Genau meine Rede, Persistenz ist mehr als Serialisierung, und darum finde ich, dass eine Datenklasse auch nicht selbst entscheiden soll, welche Form der Persistenz verwendet wird (in deinem Fall eben serialisieren). Daher empfehle ich die Persistierung von der Datenklasse zu trennen um entsprechend Wahlmöglichkeiten zu besitzen, um auch z.B: die Daten auf eine Tabelle in der Datenbank abbzubilden.
Aber Vererbung bedeutet im C++-Sinn eben mehr. So fügt man einen vtable der Klasse hinzu etc.
Jetzt bin ich aber gespannt, wie andere Sprachen virtuelle Methoden auflösen, wenn nicht mit einer Art vtable.
-
boost`rockt schrieb:
rüdiger schrieb:
Wer die Funktion nicht versteht, hätte kein Programmierer werden sollen. Wobei die Überladung wirklich ein wenig sinnlos ist in dem Fall.
Der Operator macht in diesem Fall einfach keinen Sinn, da man & einfach nicht mit serialisieren in Verbindung bringt, wenn man es nicht weiß. Das hat nichts mit Unwissenheit des Programmierers zu tun. Aber ein derartiger "Fehler" ist in diesem Fall natürlich erlaubt, weil es um boost geht ..
Da muss ich dir recht geben. Die Überladung des operator& ist mir unverständlich. Ein << wäre logisch gewesen oder einfach eine funktion serialize.
rüdiger schrieb:
Bietet eben den Vorteil, dass man je nach Datentechnologie eine andere Form der Persistenz wählen kann (z.B: wird man kaum in eine Datenbank serialisieren, sondern eher auf Tabellen abbilden).
Bietet den Vorteil gegenüber welcher Lösung?
Persistenz ist übrigens mehr als Serialisierung
Genau meine Rede, Persistenz ist mehr als Serialisierung, und darum finde ich, dass eine Datenklasse auch nicht selbst entscheiden soll, welche Form der Persistenz verwendet wird (in deinem Fall eben serialisieren). Daher empfehle ich die Persistierung von der Datenklasse zu trennen um entsprechend Wahlmöglichkeiten zu besitzen, um auch z.B: die Daten auf eine Tabelle in der Datenbank abbzubilden.
Wenn ich eine Klasse in eine Datenbank oder eine Textdatei serialisiere, dann ist das immer noch Serialisierung... Und ob ich das in einer Methode der Klasse, zusätzlichen Klasse, globalen Funktion oder wo auch immer mache, das ändert nichts daran und schränkt mich auch nicht in den Möglichkeiten ein, unterschiedlich zu serialisieren.
Was ich meinte, das Persistenz mehr Dinge umfasst als simple Serialisierung, die Serialisierung ist nur ein Schritt und zwar der einfachste. Folgender Artikel gibt dazu einen schönen Überblick (auch wenn er das Design einer Persistenz-Bib für Common Lisp beschreibt) http://weitz.de/eclm2006/rucksack-eclm2006.txt
Aber Vererbung bedeutet im C++-Sinn eben mehr. So fügt man einen vtable der Klasse hinzu etc.
Jetzt bin ich aber gespannt, wie andere Sprachen virtuelle Methoden auflösen, wenn nicht mit einer Art vtable.
hmm, zB über einen Nachrichten Dispatcher :p Nein, ich verstehe schon was du meinst. Aber da wir hier ja eh gerade von den Unterschieden zwischen Java und C++ reden. Java hat im Grunde immer einen vtable. Aber zum einen kann der JIT virtuelle Funktionen eh besser auflösen, als ein normaler Compiler und zum anderen muss man damit einfach leben, wenn man eine Klasse in Java benutzt.
In C++ geht man anders vor, da geht man nicht von oben nach unten ("Ich bepack mich mit so viel Last und schau mal was ich dann noch los werde"), sondern von unten nach oben vor ("Ich schleppe nur das, was dringend erforderlich ist").
-
"Ich bepack mich mit so viel Last und schau mal was ich dann noch los werde"
Naja in Java ist es eben keine Last. Ob ich ein Serializable "implementiere" oder nicht ist eigentlich egal, weil Serializable eh nur eine semantische Sache ist.
Aber ich weis schon was du meinst
