Serialisierung ...

[GeorgC++]

Die Serialisierung geht bei .NET denkbar einfach.
Doch ein Problem:

Serialisierung:

FileStream fs = new ...
...Serialisize(fs ...
fs.Close();

Deserialisierung:

FilStream fs = new ...
...Deserialisize(fs);
fs.Close(); // Dieses "fs.Close()" fehlt in den meisten Büchern.
// Wieso ?

[Fedaykin]

Weil es meist auch ohne geht, da Close automatisch beim Disposen von FileStream aufgerufen wird. Und das Dispose wird spätestens beim entfernen des Filestreams über den GC ausgeführt. Hat aber einen dummen Nebeneffekt. Das ganze ist nicht deterministisch.

[loks]

da sollte eh stehen:

using(FileStream stream...)
{
}

und dann brauchts kein Close.

[Firefighter]

@Fedaykin: So einfach ist das nicht. Spiel mal folgendes durch. Erzeuge dir mal einen Streamwriter, schreib was in den Strea(sw.Writeline("hallo") reicht schon), und lass das Close weg und öffne dann mal deine Datei, du wirst sehen da steht rein gar nichts drinne. Und der GC räumt sowieso nur auf wenn zu viel speicher genutzt wird, zwischenzeitlich räumt der da gar nichts auf.

[Fedaykin]

@Firefighter. Das meinte ich mit nicht deterministisch. Um Daten wirklich zu schreiben reicht ja ein Flush() da brauchts kein Close. Das Close löst ja auch nur noch ein letztes Flush aus.

[Firefighter]

Ja das ist ja auch richtig. Es kam in deinem Post nur so rüber als wenn man Streams gänzlich ohne Close nutzen kann und das sich der GC drum kümmert, was meines erachtens nicht so prickelnd ist. Zumal er sich eben nicht drum kümmert, kommt kein Close ist das Filehandle solange reserviert bis das Betriebssystem es wieder freigibt. Kam vielleicht etwas anders rüber was du meintest als ich es aufgefasst habe.

[Dravere]

Fedaykin schrieb:

@Firefighter. Das meinte ich mit nicht deterministisch. Um Daten wirklich zu schreiben reicht ja ein Flush() da brauchts kein Close. Das Close löst ja auch nur noch ein letztes Flush aus.

Close gibt auch noch die Ressourcen frei, also bei einem File wäre dies das File-Handle. In Sprache mit Destruktoren, wo klar definiert ist, wann sie aufgerufen werden, kann man das Close weglassen. Aber ohne diese klare Definition, halte ich es für unsauber, wenn man Close nicht aufruft. Nicht ohne Grund gibt es in C# die using Möglichkeit. Man sollte System-Resourcen nie länger belegen, als man sie tatsächlich benötigt.

Einfaches Beispiel:
Dein Programm soll etwas speichern, der Benutzer hat ihm gesagt wo. Die Speicherung wird ausgeführt, dein Programm lässt aber das Close weg, weil du es nicht hingeschrieben hast. Das File liegt auf einer USB-Festplatte. Der Benutzer will dein Programm nicht schliessen, er möchte nur die USB-Festplatte abhängen. Kann er aber nicht, weil du noch ein offenes Handle auf das File auf der Festplatte hast.

Grüssli

[Fedaykin]

Dravere schrieb:

Kann er aber nicht, weil du noch ein offenes Handle auf das File auf der Festplatte hast.

Grüssli

Hardwaremäßig kann er das schon. Ob er das jemals ein zweites mal machen wird ist dabei aber ungewiss