K
Naja:
Knuddlbaer schrieb:
Wie soll denn der Serializer von Deinem Konstruktor wissen um dort die Werte einzutragen ?
Knuddlbaer schrieb:
Hm.. mal merken, kann noch nützlich sein das fehlende Konstruktoren auch Laufzeitprobleme erzeugen können. Man lernt nie aus
Für was ein Standardkonstruktor benötigt wird ist klar. Ich hätte jedoch nicht vermutet, das soetwas erst zur Laufzeit festgestellt wird.
Schauen wir uns mal die Signatur an:
public:
void Serialize (
XmlWriter^ xmlWriter,
Object^ o
)
Dann schauen wir uns mal zwei Zeilen aus dem Beispiel der MSDN an:
OrderedItem^ i = gcnew OrderedItem;
serializer->Serialize( writer, i );
Es wird eine Instanz von OrderedItem übergeben.
Da ich mich nicht im Detail mit dem XMLSerializer beschäftigt habe ist für mich nicht ersichtlich, für was der Konstruktor denn benötigt wird. Das Objekt IST bereits kontruiert, also ist das hier ja bereits gegeben:
Erst wenn es inszanziiert ist, kann er die public Properties/Fileds entsprechend setzen.
Beim Deserialisieren wird ein System::Objekt zurück gegeben, da könnte ich mir eine solche Exception vorstellen auch wenn ich aus guten alten C++ Zeiten eher einen Compilerfehler erwartet hätte.
Das Problem wird IMHO aber daran liegen, das ich mich bisher nicht im Detail mit dem Serializieren und dessen internen abläufen beschäftigt habe. Es bleibt daher nur die vermutung übrig, das der Serializer das Objekt genauestens untersucht - er muss ja Informationen wegschreiben um das Objekt später zu Deserialisieren. Die Signatur der Methode erwartet keinen Typen und gibt ein System::Object ^ zurück. (Also etwas anderst als mit einfachen op>> und op<< , dessen vorgehensweise ich Gedanklich mit dem Serialisieren beim Antworten der Fragen gleich gesetzt habe. Dort muss man wissen was man ausliest. Hier scheint bereits eine Fabrik implementiert zu sein mit der Eigenschaft zuvor genauestens auf Serialisierbarkeit zu prüfen bevor das Objekt geschrieben wird. Schade finde ich dann:
Die Serialize-Methode konvertiert die öffentlichen Felder und Lese-/Schreib-Eigenschaften eines Objekts in XML. Methoden, Indexer, private Felder und Nur-Lesen-Eigenschaften werden nicht konvertiert.
das man für die priv. Eigenschaften dann doch Hand anlegen muss).
Die Vermutungen werden natürlich bei Gelegenheit durch fleissiges Lesen ausgebessert. Bis dahin lebe ich mal mit der Vermutung das es so in die Richtung sein könnte und war mit diesen Wissenslücken einfach davon überrascht das fehlende Konstruktoren überhaupt Laufzeitfehler auslösen können.
Also: Interesanntes Thema, dessen Wissen sich lohnt bevor man es einsetzt um genau das zu liefern was vom Serializer erwartet wird bzw. um alles zu Serialisieren was benötigt wird
(Sag ja, man lernt nie aus und die Liste der zu lesenden Themen wird nie beendet sein
