Frage zum Buffer eines Streams

[sirius]

Zitat:

Zitat von alleinherrscher

Dann würden doch bei einem weiteren Read vorgang die Daten an das ENDE von Buffer weitergeschrieben, richtig? Gibt es keine Möglichkeit (so ähnlich wie beim Stream selbst), mitten in den Buffer nochmal was reinzuschreiben bzw einlesen zu lassen?

:wall: Schon wieder vergessen, dass die einzelnen Blöcke ja auch den Filestream "überschreiben" können.
Dann ist die Zeile natürlich Quark.

Dann dürfte doch alles funktionieren (wenn die Rechnung mit Start und ReadStart stimmt). Du kannst problemlos überschreiben.

Buf (bzw. buffer) zeigen doch nur auf ein Stück Hauptspeicher. Und dort schreibst du rein ohne dich für den Inhalt oder für die Speicherreservierung zu kümmern. Der Inhalt ist dir eh wurscht und die Speicherreserveirung muss bei allen Streams die aufrufende Funktion machen.

[alleinherrscher]

Okay, fehler in der Positionsberechnung von ReadStart behoben. Also bei mir läufts jetzt ganz gut...

SaveToFile ist allerdings noch buggy...

//edit: wieder ein paar Fehler bzgl. Setsize gefunden...

[shmia]

Die Klasse TBufferStream sollte so konstruiert sein, dass man ein beliebiges TStream-Objekt übergibt (anstelle eine Dateinamen).
Wie man's richtig macht kann man z.B. in der Unit JclStreams der JCL nachschauen.

[alzaimar]

Erstmal muss ich sagen: Echt nette Komponente. :thumb:

Ein paar Sachen fallen mir auf:

Wieso swapt ihr eigentlich selber FMemory auf die Platte? Kann man das nicht auch Windows überlassen? Ich meine, das Windows das bessere Memory management hat, oder irre ich mich? Ich halte das auch für eine Performancebremse, denn entweder habt ihr ALLES im RAM, oder ALLES auf der Platte...

Ich hab den Code nur überflogen, aber mir fällt da eine kleine Schwachstelle auf:
Wenn ich mehrmals an die gleiche Stelle etwas schreibe, dann hängt ihr trotzdem immer einen 'aPart' an die PartsInfo-Liste an. Das ist überflüssig. Das ist mit der (zugegebenermaßen ziemlich einfach wie genialen) Methode mit dem einen FMemory - Stream nicht optimal lösbar. Wenn man jedoch davon ausgeht, das in dem Stream nicht sonderlich viel überschrieben wird, ist das nicht so wild.

Die Routine GetTempName ist blöd, nehmt lieber die WinAPI-Version

Delphi-Quellcode:

Function TempPath: String;
Var
  i: integer;

Begin
  SetLength(Result, MAX_PATH);
  i := GetTempPath(Length(Result), PChar(Result));
  SetLength(Result, i);
  IncludeTrailingPathDelimiter(Result);
End;

Function TempFilename: String;
Begin
  SetLength(Result, MAX_PATH + 1);
  GetTempFileName(PChar(TempPath), 'CSI', 0, PChar(result));
End;

In der SaveToFile-Methode steckt ein Denkfehler:

Delphi-Quellcode:

...
   if i>=PartsInfo.Count-1 then //alle Elemente in FMemory sind Sortiert hinterheinander
       if (FMemory is TMemoryStream) then  // => FMemory ist bereits fertiger Stream!  DENKFEHLER!!!
          TMemoryStream(FMemory).SaveToFile(Filename)
...

Also: Ich schreibe an Pos:1 und Pos:100 jeweils ein Byte (z.B. A und B). Dann steht in PartsInfo (Pos:1, Size:1, FindAtPosition:0) sowie (Pos:100, Size:1, FindAtPosition:1) und der FMemory-Stream enthält 'AB'. Das ist aber nicht der fertige Stream, oder irre ich mich?

Ihr könntet die einzelnen Parts aus Partinfo jeweils mit

Delphi-Quellcode:

  FMemory.Seek (FindAtPositon, soFromBeginning);
  stDestStream.Seek (PositionInStream, soFromBeginning);
  stDestStream.CopyFrom (FMemory, Length);

in den Ziel-Stream schreiben

Na ja, und dann wären da noch ein paar kosmetische Kleinigkeiten: aPart ist ein *schlechter* Bezeichner für einen Datentypen. Auch würde ich daraus eine Klasse machen.

Ansonsten: Echt Cool.