Aha Momente

[jaenicke]

Das erinnert mich an das alte "file of" Konstrukt. Mit beliebigen generischen Typen würde das allerdings nicht funktionieren.

Die Idee verstehe ich durchaus, aber ich sehe keine Möglichkeit einer Umsetzung. Im Grunde wäre die Anforderung quasi ein ORM auf Streambasis...

[Neutral General]

Die einzige Möglichkeit die ich sehe ist sowas:

Delphi-Quellcode:

IStreamable = interface
  procedure LoadFromStream(Stream: TStream);
  procedure SaveToStream(Stream: TStream);
end;

TStream<T: IStreamable> = class(TCustomMemoryStream)
  // ...
end;

Aber das hilft auch nicht soo viel.

[himitsu]

Binäre Daten sind eh bissl blöd.
Wenn, dann vielleicht ein ORM um TReader/TWriter (zwar auch binär, aber inkl. Formatierungdaten und optional auch als Text-Version)

Aber dann vielleicht eher in Richtung BSON (binäres JSON) oder CompressedXML,
wobei man TReader (das was die DFMs im Delphi nutzen) auch als typsicherere Variante des JSON/BSON ansehen könnte.

[Benmik]

Wofür ist ein TPointerStream nützlich?

[himitsu]

Damit du mit den Methoden eines Streams, und Allem was Streams unterstützt, im Speicher von irgendwas Anderem rumwurschteln kannst.
Also du bekommst z.B. von einer API einen Buffer (x Bytes) und kannst direkt mit diesem Speicher (ohne umzukopieren) das dennoch als Stream verarbeiten.

Du kannst damit auch in einem anderen TMemoryStream/TBytesStream (in dessen Speicher oder "sicher" nur einem Teil davon) mit einem weiteren Stream arbeiten usw.
Das macht es Einfacher Dinge zu verschachteln und spart Arbeit/Speicher ... z.B. wenn in einem großen Stream mehrere Bilde drin stecken, dann auf den gewünschten Teil den PointerStream drauf und das dann an LoadFromStream von irgendwas, ohne vorher umzukopieren.

[Neutral General]

Sowas hab ich 2010 programmiert und hier hochgeladen (TVirtualStream):
https://www.delphipraxis.net/113289-mapped-streams.html

Ist sogar in der JWSCL gelandet
https://sourceforge.net/p/jedi-apili...sclStreams.pas

[himitsu]

BJSON/BSON ist technisch schon ein bissl wie die DFM im Delphi

Ein Byte für den Typ und dann die Daten, also in den Daten steht drinne, wie man sie interpretiert.

Zitat von himitsu:

Binäre Daten sind eh bissl blöd.
Wenn, dann vielleicht ein ORM um TReader/TWriter (zwar auch binär, aber inkl. Formatierungdaten und optional auch als Text-Version)

Aber dann vielleicht eher in Richtung BSON (binäres JSON) oder CompressedXML,
wobei man TReader (das was die DFMs im Delphi nutzen) auch als typsicherere Variante des JSON/BSON ansehen könnte.

[dummzeuch]

Im Buch "Algorithms and Data Structures" (von 2001, zweite Auflage von 2006) beschreibt Julian Bucknall ein sich selbst dokumentierendes Dateiformat. Das ist ein File of Records, welches zusätzlich einen Header enthält, der den Record beschreibt. Wenn man die Struktur dieses Headers kennt, kann man einen generischen Reader dafür schreiben (und theoretisch auch einen Editor)

In der Firma benutzen wir ein auf dieser Idee basierendes Dateiformat, welches noch zusätzliche Angaben zur Datei und außerdem eine Prüfsumme im Header enthält. Das ist extrem praktisch, da unser Reader dafür beliebige unserer Datendateien anzeigen und auch grafisch darstellen kann.

Hauptvorteil: Durch binäres Format deutlich kleinere Dateien als in irgendwelchen Textformaten.

[himitsu]

Jo, kleiner, aber vorallem auch schneller/einfacher zu lesen, weil man nichts erst parsen muß, bzw. auch Fehlerunanfälliger (besonders, wenn auch noch inkl. Prüfsumme).

Binäre-DFM, BSON, CompressedXML, ...
Text-DFM, JSON, XML, ...

[jaenicke]

Zitat von dummzeuch:

Im Buch "Algorithms and Data Structures" (von 2001, zweite Auflage von 2006) beschreibt Julian Bucknall ein sich selbst dokumentierendes Dateiformat. Das ist ein File of Records, welches zusätzlich einen Header enthält, der den Record beschreibt. Wenn man die Struktur dieses Headers kennt, kann man einen generischen Reader dafür schreiben (und theoretisch auch einen Editor)

DBase?

Ja, ich habe so etwas auch schon selbst geschrieben, aber damals kannte ich Datenbanken, z.B. eben auch einfache dateibasierte Datenbanken, noch nicht. Die machen ja genau das, was du dort beschrieben hast (ja, ohne Unterstrukturen, ich weiß). Und darauf aufsetzende ORMs können dann auch damit arbeiten.