🚀 go-pugleaf

Hi,
Joerg Bornemann (juri@compi.baltic.de) wrote:
: Nico Josuttis wrote:
: > In dem Fall musst Du angeben, dass es als Zeichen rausgehen soll.
: > Also:
: >     >        datei << (char)datstr;

Das hat aber, zumindest konzeptionell, immernoch nichts mit einer
binaeren Ausgabe zu tun!  Sicher wird das passende Bitmuster
gespeichert, aber der korrekte Weg binaere Daten (mit einem 'ostream')
zu speichern ist 'ostream::write(char *, size_t)' ('char*' statt
'void*' ist noetig, da 'void' keine Groesse hat). Genaugenommen,
muesste man fuer binaere Daten einen aehnlichen Layer wie 'ostream' und
Co., etwa 'obstream' bauen, der eben gerade fuer NICHT formatierte
Ausgabe ist ('ostream' und Co. sind halt fuer formattierte,
menschenlesbare Ein-/Ausgabe gedacht). Da die 'streambuf'-Abstraktion
nichts mit Formattierung zu tun hat, koennte man die existierenden
'streambuf's (z.B. 'filebuf') weiterverwenden. Lediglich die Inserter
and Extractor Funktionen (i.e. 'operator>>()' und 'operator<<()')
muessten neu geschrieben werden. Das ist allerdings eh klar, da man
ganz andere Anforderungen hat. z.B. wuerde man ja eine komplexe Zahl
einfach als zwei 'double's (ggf. mit einem 'bool' oder 'enum' fuer die
gewaehlte Repraesentation) abspeichern und nicht mit Klammern oder so.
Auf dieser Basis liesse sich dann auch sowas wie 'network byte
ordering' einbauen, damit die binaeren Files ueber verschiedene
Platformen (mehr) portable sind (ganz bekommt man es damit auch noch
nicht hin).

: Tat es. Allerdings kann ich damit nur 8 Bit-Werte speichern.
: Wie speichere ich z.B. 0x4142?

: datei << char(datstr >> 8) <<  char(datstr)

: ist eingentlich ein bischen umstaendlich...

Kein Wunder. "Richtig" waere ja auch 'datei(static_cast<char*>(datstr),
sizeof(datstr))' (fuer eine platform-dependent Repraesentation).

: > (Ich will lieber nicht nach dem Sinn einer solchen Konstruktion fragen,

: Der Sinn? Ich muss viele Zahlen in einer Datei speichern...
: Kann man das anders (besser) machen?

Wenn man die Daten nicht nur temporaer, sondern dauerhaft, speichern
will, dann ist man gut beraten, sich um solche komischen Sachen wie
Byte-Order/Word-Order Gedanken zu machen. Byteweise, vom High- zum
Low-Byte, ist eine Moeglichkeit.  Je nachdem, ob und wo das File
einfach page-weise gelesen werden soll, ist das mehr oder weniger
brauchbar. Integer zu speichern ist dabei vergleichsweise einfach.
...aber 'double's zu speichern, insbesondere wenn die zwischen Rechnern
mit IEEE und mit ohne IEEE Darstellung transportiert werden sollen, ist
minderwertig (gluecklicherweise scheinen wenigstens die mit ohne IEEE
Darstellung auszusterben).

Ich hatte mal mit dem Gedanken gespielt "schnell mal" sowas wie
'ibstream' und 'obstream' zu schreiben, bin aber an so trivialen
Problem wie 'double's zu speichern gescheitert. Wenn jemand einen
sinnvollen Vorschlag fuer ein (halbwegs) Platform unabhaengiges Format
(und moeglichst auch weiss, wie man das halbwegs Platform unabhaengig
implementiert) hat, dann koennte man sowas mal angehen... "Kleinere"
Nebenanforderungen, wie etwa Typsicherheit, zu erfuellen waere auch
ganz nett :-)
--
dietmar.kuehl@uni-konstanz.de
http://www.informatik.uni-konstanz.de/~kuehl
I am a realistic optimist - that's why I appear to be slightly pessimistic

kuehl@uzwil.informatik.uni-konstanz.de (Dietmar Kuehl) writes:

> : >     >        datei << (char)datstr;

> Das hat aber, zumindest konzeptionell, immernoch nichts mit einer
> binaeren Ausgabe zu tun!  Sicher wird das passende Bitmuster
> gespeichert, aber der korrekte Weg binaere Daten (mit einem 'ostream')
> zu speichern ist 'ostream::write(char *, size_t)' ('char*' statt
> 'void*' ist noetig, da 'void' keine Groesse hat).

Ist das nicht Definitionssache?  Man könnte doch einfach sagen, das
zweite Argument gibt die Größe in Bytes (aka sizeof char) an.  Dann
könnte das erste Argument doch void* sein, und der häßliche
static_cast fiele weg.

> Ich hatte mal mit dem Gedanken gespielt "schnell mal" sowas wie
> 'ibstream' und 'obstream' zu schreiben, bin aber an so trivialen
> Problem wie 'double's zu speichern gescheitert. Wenn jemand einen
> sinnvollen Vorschlag fuer ein (halbwegs) Platform unabhaengiges Format
> (und moeglichst auch weiss, wie man das halbwegs Platform unabhaengig
> implementiert) hat, dann koennte man sowas mal angehen...

Ein plattformunabhängiges Binärformat existiert bereits, nämlich das
von Sun entwickelte XDR.  Gips auch auf anderen Kisten wie DEC
Alphas.  Irgendwer hat sogar mal eine Klasse XDRstream geschrieben,
aber das war, bevor das Standardisierungskomitee die iostreams in die
Finger bekommen hat.

> "Kleinere"
> Nebenanforderungen, wie etwa Typsicherheit, zu erfuellen waere auch
> ganz nett :-)

Fände ich gar nicht nett, weil das die Größe der Binärdarstellung
aufblasen würde, und weil es eventuell nicht sprachunabhängig ist.
Bei XDR ist sowas nicht drin; bei Bedarf könnte man sich sowas ja
oberhalb von XDR definieren.