Objekt im Speicher verschieben ; Speicherabbild erstellen

[volkard]

Nexus schrieb:

sqrt(-1) schrieb:

Probleme wie Endianess und Datenwortbreite sind kein Grund für ein Textformat.

Das kannst du sicher begründen.

Wozu? Es sind keine Gründe. Wie will er begründen, was gar keinen Halt hat?
Er kann nur Theorien widerlegen, die behaupten, man bräuchte wegen Endianess oder Datenwortbreite ein Binärformat. Dazu muß jemand begründen, weshalb er ein Textformat braucht und diese Begründung kann leicht zerfetzt werden.

[sqrt(-1)]

[quote="Nexus"]Denk mal an die vielen Probleme, die behoben oder umgangen werden müssten, wenn alles nur noch binär gespeichert würde (welche, wurde ja genannt). Und überlege dir, ob man für den Mehraufwand, ein halbwegs portables Binärformat zu realisieren, auch Energie braucht.

Der Leistungsaufwand ist um Größenordnungen geringer. Was soll denn daran komplizierter sein die Auszeichnung von Daten und Strukturen mittels Binärdaten anstatt von Text zu realisieren?

sqrt(-1) schrieb:

Probleme wie Endianess und Datenwortbreite sind kein Grund für ein Textformat.

Das kannst du sicher begründen.

Es ist doch simpel auch plattformunabhängig binär zu beschrieben in welchem Platformformat die Daten vorliegen um dann gegebenfalls Anpassungen beim Interpretieren vorzunehmen.

[sqrt(-1)]

Nexus schrieb:

Denk mal an die vielen Probleme, die behoben oder umgangen werden müssten, wenn alles nur noch binär gespeichert würde (welche, wurde ja genannt). Und überlege dir, ob man für den Mehraufwand, ein halbwegs portables Binärformat zu realisieren, auch Energie braucht.

Der Leistungsaufwand ist um Größenordnungen geringer. Was soll denn daran komplizierter sein die Auszeichnung von Daten und Strukturen mittels Binärdaten anstatt von Text zu realisieren?

Nexus schrieb:

sqrt(-1) schrieb:

Probleme wie Endianess und Datenwortbreite sind kein Grund für ein Textformat.

Das kannst du sicher begründen.

Es ist doch simpel auch plattformunabhängig binär zu beschrieben in welchem Platformformat die Daten vorliegen um dann gegebenfalls Anpassungen beim Interpretieren vorzunehmen

[Registrierter Troll]

volkard schrieb:

Wozu? Es sind keine Gründe. Wie will er begründen, was gar keinen Halt hat?
Er kann nur Theorien widerlegen, die behaupten, man bräuchte wegen Endianess oder Datenwortbreite ein Binärformat. Dazu muß jemand begründen, weshalb er ein Textformat braucht und diese Begründung kann leicht zerfetzt werden.

Bitte lesen lernen. Hier steht nirgends, dass man deswegen Textformate braucht, sondern dass man mit Textformaten weniger Probleme dieser Art hat.

Die Gründe liegen auf der Hand: Die Bedeutung von ASCII-Text bleibt eindeutig, auch wenn er auf verschiedenen Plattformen eingelesen wird. Von ganz exotischen Ausnahmen mal abgesehen. Der gleiche Parser kann somit auf vielen verschiedenen Plattformen unverändert verwendet werden.

[unskilled]

sqrt(-1) schrieb:

Nexus schrieb:

Denk mal an die vielen Probleme, die behoben oder umgangen werden müssten, wenn alles nur noch binär gespeichert würde (welche, wurde ja genannt). Und überlege dir, ob man für den Mehraufwand, ein halbwegs portables Binärformat zu realisieren, auch Energie braucht.

Der Leistungsaufwand ist um Größenordnungen geringer. Was soll denn daran komplizierter sein die Auszeichnung von Daten und Strukturen mittels Binärdaten anstatt von Text zu realisieren?

Nexus schrieb:

sqrt(-1) schrieb:

Probleme wie Endianess und Datenwortbreite sind kein Grund für ein Textformat.

Das kannst du sicher begründen.

Es ist doch simpel auch plattformunabhängig binär zu beschrieben in welchem Platformformat die Daten vorliegen um dann gegebenfalls Anpassungen beim Interpretieren vorzunehmen

boar..
jz google(oder bing(?!^^) oder such direkt bei wikipedia oder was auch immer) halt endlich mal nach endianess und datenwortbreite! (mit floating-point values wirds dann ganz lustig, weil dir der standard da(im Bezug auf den internen Aufbau) rein gar nichts garantiert xD)
es ist eben _kein_ triviales problem...

Performance ist zwar ein nicht von der Hand zu weisendes "Problem", aber was schreibst du denn für ein Programm, dass es so extrem schnell gehen muss?

bb

[sqrt(-1)]

Es ist doch offensichtlich das die Auszeichnung von Daten mittels Text bis auf die theoretisch bessere menschliche Lesbarkeit absolut Null Vorteile, aber viele Nachteile mit sich bringt. Denn letztendlich ist Text ja auch nur ein Format für Binärdaten.

Dass Datenstrukturen als Text gelesen werden können erachte ich für nicht triviale Falle (wie Konfigurationsdateien) als ganz klar nicht amortisierend, da die Strukturen sowieso dokumentiert sind oder gar die Interpretationsalgorithmen vorliegen. Dass man mit Textformaten etwas einfacher reverse-engineering betreiben kann halte ich für keine Begründung das (professionell) einzusetzen.

[volkard]

Ich schreibe gern als Text hex statt dez und spare mir damit die Divisionen. Daß ich 2 Ziffern statt einer pro Byte Nutzdaten brauche, stört mich weniger.

[sqrt(-1)]

unskilled schrieb:

boar..
jz google(oder bing(?!^^) oder such direkt bei wikipedia oder was auch immer) halt endlich mal nach endianess und datenwortbreite! (mit floating-point values wirds dann ganz lustig, weil dir der standard da(im Bezug auf den internen Aufbau) rein gar nichts garantiert xD)
es ist eben _kein_ triviales problem...

Es geht doch nur darum ob es einfacher ist binär oder im Textformat das Platformformat der Daten zu beschreiben. Was da an Standardisierungkomplexität dahinter steht ist doch in beiden Fällen identisch.

Performance ist zwar ein nicht von der Hand zu weisendes "Problem", aber was schreibst du denn für ein Programm, dass es so extrem schnell gehen muss?

Um meine Person müssen wir uns doch an der Stelle nicht kümmern.

[Registrierter Troll]

sqrt(-1) schrieb:

Es ist doch offensichtlich das die Auszeichnung von Daten mittels Text bis auf die theoretisch bessere menschliche Lesbarkeit absolut Null Vorteile, aber viele Nachteile mit sich bringt.

Ich warte gespannt auf die Aufzählung dieser vielen offensichtlichen Nachteile, die mir irgendwie zu entgehen scheinen.

[sqrt(-1)]

Registrierter Troll schrieb:

Ich warte gespannt auf die Aufzählung dieser vielen offensichtlichen Nachteile, die mir irgendwie zu entgehen scheinen.

- höherer Rechenleistungsaufwand
- größerer Speicheraufwand
- zusätzliche Komplexität des Parsers
- verleitet die Dokumentation zu Vernachlässigen

[Nexus]

Das beginnt langsam in einen Flamewar auszuarten. sqrt(-1), wir sagen nicht, Binärformate seien grundsätzlich schlechter. Natürlich gibt es berechtigte Anwendungsfälle. Du behauptest aber, dass sie Textformaten immer überlegen sind. Portabilität ist damit eindeutig aufwändiger, das beginnt ja bereits damit, dass du ein standardisiertes Format brauchst, um zu entscheiden, in welchem Binärformat die eigentlichen Informationen gelesen werden sollen.

Du kannst natürlich sowas wie ein neues, standardisiertes Binärformat erzeugen. Dann bist du aber wieder nahe am Textformat und hast die entsprechenden Nachteile: Mehr Aufwand, weil bitweise gefrickelt werden muss und teilweise redundante Informationen. Trotzdem musst du auf sehr viele implementierungsspezifische Dinge Rücksicht nehmen. Im Bezug auf C++ heisst das, dass du oft undefiniertes Verhalten hast.

Da mit Textformaten wie Unicode bereits internationale Konventionen existieren, ist Portabilität damit um einiges einfacher. Auch ist ein besserer Austausch möglich, wenn es sich um ein etabliertes Format handelt.

[unskilled]

sqrt(-1) schrieb:

Registrierter Troll schrieb:

Ich warte gespannt auf die Aufzählung dieser vielen offensichtlichen Nachteile, die mir irgendwie zu entgehen scheinen.

- höherer Rechenleistungsaufwand
- größerer Speicheraufwand
- zusätzliche Komplexität des Parsers
- verleitet die Dokumentation zu Vernachlässigen

- höherer Rechenleistungsaufwand
vernachlässigbar (hdd-zugriff dauert ja wohl um größenordnungen länger als nen paar cpu-takte)
- größerer Speicheraufwand
also ob ein Programm nun ne große Datei oder eine halb so große große Datei erstellt, ist mir relativ wurst...
ist aber in meinen augen der einzige wirkliche nachteil(da es mehr zu schreiben/lesen gibt, dauert es auch länger - wobei der flaschenhals ja das lesekopf positionieren und nicht das lesen an sich sein wird...
- zusätzliche Komplexität des Parsers
der binäre parser würde sicherlich ähnlich komplex sein... vrmtl so gar noch komplexer...
- verleitet die Dokumentation zu Vernachlässigen
was nen nachteil...

bb

[Registrierter Troll]

sqrt(-1) schrieb:

- höherer Rechenleistungsaufwand

Das ist doch angesichts der vorhandenen Rechenpower schon seit Jahren ein vernachlässigbarer Faktor. Ob das Parsen 10 ms oder 100 ms dauert ist in den wenigsten Fällen relevant.

- größerer Speicheraufwand

Hierfür gilt das Gleiche. Speicher ist reichlich vorhanden.

- zusätzliche Komplexität des Parsers

Wenn man mal von C++ ausgeht, ist alles schon an Board was man dazu braucht. Einen einfacheren und portableren Parser als einen der Text liest, wirst du kaum schreiben können. Und du musst ihn nicht für jede Plattform anpassen.

- verleitet die Dokumentation zu Vernachlässigen

Das ist eine haltlose Behauptung ohne jede Substanz.

Man muss nicht alles unbedingt in ein Textformat zwängen, das stimmt schon. Bitmaps würde ich so nicht speichern.
Aber für viele Fälle ist es nun mal das Einfachste, und es macht den geringsten Aufwand.

[Nexus]

Mit dem Argument, dass heutige RAM/Prozessoren so gut sind, dass es nicht mehr auf Performance ankommt, wäre ich sehr vorsichtig (ist übrigens eines der Standardargumente von C++-Bashern). Das mag zwar in vielen Fällen stimmen, trotzdem sollte man versuchen, im vernünftigen Rahmen effizient zu programmieren. 10ms oder 100ms mag tatsächlich egal sein, ob es einen oder zehn Tage dauert vielleicht weniger.

Das meine ich jetzt eher allgemein. Doch je nach Anwendung kann der Einsatz binärer Formate durchaus durch die grössere Geschwindigkeit motiviert sein.

[volkard]

Wenn ich einen Stream mit strukturieten Daten schnell schreiben und lesen will, also sehr schnell, ist das Standardvorgehen eh nicht so optimal. Ein paar kleine Tricks muß ich schon machen. Insbesondere muß ich Konstruktoren benutzen. Weil das bei eingebauten Typen nicht geht, für die ein Umweg dazu. Das konstruietre Codebeispiel machts deutlich:

class Derived:public Base{
   Foo f;
   int i;
   string s;
   Array<int,10> a;
   Vector<int> v;
public:
   Derived(istream& in):
      Base(in),
      f(in),
      i(readInt(in)),
      s(readString(in)),
      a(in),
      v(in){
      }
   void saveTo(ostream& out){//virtual in Base
      Base::saveTo(out);
      f.saveTo(out);
      writeInt(i,out);//ist nur out<<i<<'\n'
      writeString(i,out);//schreibt z.B. "hallo" oder 5:hallo
      a.saveTo(out);
      v.saveTo(out);
   }
};

Die Geschwindigkeit ist erprobt und enorm. Es ist null problemo, beim Schreiben auch den Klassennamen davorzuschreiben, damit eine lesende Factory das dann richtig zuordnen kann. Es ist auch kein Problem, da noch ein klitzbißchen zu erweitern, daß am Ende in der Datei so Sachen stehen:

Mob{
  ID=4ff3ab0
  Name=16:Conan der Barbar
  Position{
    x=3456
    y=334
  }
  Backpack{
    6:32f7,4480,32fa0b,deadbeef,123,8678333
  }
}

Dazu ist es nur nötig, die Schnittstelle zu ändern zu

void saveTo(ostream& out,char const* name,int ident);

und saveTo ruft in allen Unteraufrufen halt was wie poition.saveTo("Position",ident+2) auf. Man beachte, daß Stringgrößen und Arraygrößen immer vorher stehen, damit der Konstruktor erst allokieren und dann lesen kann. Wo andere für einen Spielstand 30 Minuten brauchten, war ich in 30 Sekunden durch. Aber das habe ich zuletzt vor 10 Jahren gemacht, ich vermute aber, die Technik ist noch nicht schlecht geworden.

Automatisch ist die Erweiterung für Binärstreams eingebaut.

class Derived:public Base{
   Foo f;
   int i;
   string s;
   Array<int,10> a;
   Vector<int> v;
public:
   Derived(istream& in):
      Base(in),
      f(in),
      i(readInt(in)),
      s(readString(in)),
      a(in),
      v(in){
      }
   Derived(BinaryInputStream& in):
      Base(in),
      f(in),
      i(readInt(in)),
      s(readString(in)),
      a(in),
      v(in){
      }
   void saveTo(ostream& out){//virtual in Base
      Base::saveTo(out);
      f.saveTo(out);
      writeInt(i,out);//ist nur out<<i<<'\n'
      writeString(i,out);//schreibt z.B. "hallo" oder 5:hallo
      a.saveTo(out);
      v.saveTo(out);
   }
   void saveTo(BinaryOutputStream& out){//virtual in Base
      Base::saveTo(out);
      f.saveTo(out);
      writeInt(i,out);//ist nur out<<i
      writeString(i,out);//schreibt z.B. "hallo" oder \5hallo
      a.saveTo(out);
      v.saveTo(out);
   }
};

Damit kann man dann die 30 Sekunden vermutlich noch ein wenig drücken, obwohl ich es immer nur als Option freigehalten habe, die ich dann doch nicht benutzte. Die meiste Zeit wird bei sowas eh für new-Aufrufe in Strings oder Vectoren verbraten und für Hashtable- oder map-Nachguckerchen, um Zeigerverknüpfungen zu bauen.

Fazit meinerseites: Es ist meistens nicht notwendig, binär zu speichern, aber es tut auch nicht weh, es ist kein Zusatzausfwand und es ist nicht unmöglich.

[volkard]

Es ist nicht zu vernachlässigen, wie schnell Festplatten Daten liefern können.
Ich habe mir ein Programm gebaut, das auf der Platte Duplikate sucht und immer wenn in C:\toMove\... eine Datei ist, die auch woanders in C:\... ist, mir die aus C:\toMove\... löscht. Dazu vergleicht es erst Dateigrößen, nur bei gleichgroßen Dateien berechnet es Checksummen, nur bei gleichen Checksummen vergleicht es byteweise die beiden Dateien und nur wenn sie byteweise gleich sind, löscht er die aus C:\toMove\....
Oh, meine Platte hat es nötig. Zuerst hatte ich für die Checksummen x=x*compilezeitkonstanteprimzahl+readByte() genommen. Aber das hatte eine Prozessorauslastung von konstant 100%. Jetzt nehme ich CRC64 und die Prozessorauslastung wackelt ein wenig über der Kernelprozessorauslastung(zwischen 80 und 100) rum.

Mein Fazit: Die Platte ist so sagenhaft schnell, wenns um sequentielles lesen/schreiben geht, da0 es doch kein blanker Unfug ist, sein Programm auch schnell zu machen.

[Registrierter Troll]

Nexus schrieb:

Mit dem Argument, dass heutige RAM/Prozessoren so gut sind, dass es nicht mehr auf Performance ankommt, wäre ich sehr vorsichtig (ist übrigens eines der Standardargumente von C++-Bashern). Das mag zwar in vielen Fällen stimmen, trotzdem sollte man versuchen, im vernünftigen Rahmen effizient zu programmieren.

Klar kommt es irgendwann auf die Performance an, aber man kann in der Regel schon eine ganze Menge Text parsen, bevor man überhaupt mal in einen Bereich kommt, wo es einen fühlbaren Unterschied zum binären Lesen gibt.
Ich will auch gar nichts gegen Binär gesagt haben, ich halte bloß Text bei Vielem für das bessere Default und die genannten Gegenargumente dagegen für sehr schwach.

volkard schrieb:

Es ist auch kein Problem, da noch ein klitzbißchen zu erweitern, daß am Ende in der Datei so Sachen stehen:

Das sieht fast schon aus wie JSON, was ich gerne und oft benutze.

[volkard]

Registrierter Troll schrieb:

volkard schrieb:

Es ist auch kein Problem, da noch ein klitzbißchen zu erweitern, daß am Ende in der Datei so Sachen stehen:

Das sieht fast schon aus wie JSON, was ich gerne und oft benutze.

JSON hörte ich gerade zum ersten mal. google google...
Ahh. Halt ein paar Minuten nachgedacht und man hat mehr Menschenlesbarkeit und Performance als XML. Wobei JSON noch weitere Vorzüge hat, die mich weniger betreffen.

[Dravere]

Also ich stelle mich da jetzt mal zum Teil auf die Seite von sqrt(-1). Aus dem einfachen Grund, dass man alle negativen Gründe eines Binärformates, welche ihr aufzählt, auch bei einem Textformat findet. Gehen wir mal durch:

Endianess
Ich erinnere mal an UTF-16BE, UTF-16LE, UTF-32BE, UTF-32LE.

Wortbreite
Ehm, in welchem Format war nun dieses Textfile kodiert? Latin1, UTF-16BE, UTF-8, usw. usf.? Also wieviele Bytes belegt jetzt ein Character? Und wie muss man diese Character interpretieren? Nur mal eine kleine Liste:
http://en.wikipedia.org/wiki/Character_encoding#Popular_character_encodings

Standardisiertes Format
Kommt mir nicht mit XML! XML ist sowas von aufwändig zum parsen! 800kb an Daten, kannst du bereits zwischen 500 bis 1000ms warten. Wenn du dann mehrere Megabytes oder gar Gygabytes an XML Daten verarbeiten willst, da kannst du schlafen gehen. Auch ist der XML Standard ein Witz. Wenn ihr XML in lesbarer Form schreiben wollt, also mit Absätzen und Einrückungen, dann ist das nicht nach XML Standard, bzw. eure Whitespaces sind dann eigentlich XML Daten. Dadurch wird es zum Teil als Parser sehr schwer zu wissen, ob man nun das Zeug ignorieren soll/darf oder nicht. Wenn du XML wirklich so verwendest, wie es der Standard vorschreibt, dann kannst du es überhaupt nicht lesen.
Für binäre Daten gibt es durchaus auch standardisierte Formate. Ich möchte hier nur mal zum Beispiel SQLite nennen, eine embedded Datenbank.

Platformunabhängig
\r?
\r\n?
\n?
Auch so eine Sache, die mir gerade noch einfiel

Sonstige negativen Punkte? Ich bin sicher, ich kann so gut wie alles auch auf Textformate anwenden. Textformate sind meiner Meinung nach völlig überbewertet. Es gibt mit ihnen fast gleich viele Probleme und gerade wenn man so schreckliche Formate wie XML verwendet, verbratet man noch eine Menge an Zeit fürs Parsen. Auch können Textdaten keine Dinge wie Jumptables oder sinnvolle Metadaten enthalten, durch welche man schnell an gewisse Informationen in einem grösseren File herankommt, ohne das gesamte File wirklich parsen zu müssen. Man kann also nicht einfach Datenblöcke überspringen.

Den einzigen Vorteil, welcher ich bei einem Textformat sehe, ist die Tatsache, dass man mit jedem einfachen Editor das File editieren kann. Wobei es allerdings auch da zu Problemen kommen kann, weil es viel zu viele Zeichenkodierungen gibt. Und auch mit Unicode ist das so eine Sache, da immer noch viele kein BOM (Byte Order Mark) verwenden. Bzw. ich kenne auch viele Editoren, welche kein UTF-32 können oder kein UTF-16BE, bzw. UTF-16LE, usw. usf.
Auch ist es fraglich, ob man immer möchte, dass jeder einfach mit einem Editor an den Daten rumpfuschen kann

Ich persönlich setze regelmässig beide Formate ein, oft auch in gemeinsamer Kombination. Habe zum Beispiel auch schon sowas gemacht, dass ich ein Textfile hatte und dazu ein binäres File, welches Sprungdaten des Textfiles hatte. Natürlich war es dann verboten das Textfile in einem Editor zu verändern, ohne das Sprungdaten File zu aktualisiern.

Grundsätzliche Aussage von mir: Textformate haben keinerlei offensichtlichen Vorteil gegenüber Binärformate. Man sollte nicht immer sofort zu Textformaten greifen und lieber mal überlegen, ob es nicht auch ein Binärformat tun würde. Vor allem bei grösseren Datenmengen habe ich schon öfters erlebt, dass ein Binärformat einige Vorteile brachte, zum Beispiel nur teilweises Lesen oder auch schnelleres Lesen des gesamten Files. Es gibt meiner Meinung nach viele Anwendungen, welche Textformate einsetzen, obwohl sie mit einem Binärformat besser gefahren wären (Eines der absolut dämlichsten Textformate ist zum Beispiel SVG).

Grüssli

[Registrierter Troll]

Dravere schrieb:

Endianess
Ich erinnere mal an UTF-16BE, UTF-16LE, UTF-32BE, UTF-32LE.

UTF-8 hingegen ist unabhängig von Endianess, sehr weit verbreitet und recht gut unterstützt. Für manche Anwendungsfälle reicht sogar ASCII, zB. wenn man nur Zahlen speichert.

Wortbreite
Ehm, in welchem Format war nun dieses Textfile kodiert? Latin1, UTF-16BE, UTF-8, usw. usf.? Also wieviele Bytes belegt jetzt ein Character?

Man muss die Kodierung kennen, stimmt. Aber wenn man sie kennt, sind verschiedene Wortbreiten in der Regel ohne weitere Unterscheidung im Code automatisch abgedeckt. Wenn man aber lediglich seine ints auf dem x86-Windows-PC binär geschrieben hat, und auf dem 64bit-PPC-Mac wieder einlesen will, muss man Code dafür schreiben.

Standardisiertes Format
Kommt mir nicht mit XML! XML ist sowas von aufwändig zum parsen!

Standardisieren kann man binäre Formate genauso wie Textbasierende, insofern ist das sowieso kein Argument.
Immerhin sind aber die Kodierungen standardisiert und weitestgehend portabel, bei Binärdaten sind schon einfach nur blanke Zahlen ein potenzielles Problem.
XML ist bloated und wird viel zu oft für Fälle eingesetzt, wo es simplere Formate wie JSON, ini oder oft sogar nur CSV auch tun würden.

Platformunabhängig
\r?
\r\n?
\n?
Auch so eine Sache, die mir gerade noch einfiel

Das ist eine wirklich ärgerliche Sache, die man aber einfach in den Griff bekommt. Zumindest nicht schwieriger als unterschiedliche Endianess.

Auch ist es fraglich, ob man immer möchte, dass jeder einfach mit einem Editor an den Daten rumpfuschen kann

Security by obscurity ist ein sehr fragwürdiges Konzept

Man sollte nicht immer sofort zu Textformaten greifen und lieber mal überlegen, ob es nicht auch ein Binärformat tun würde.

Man sollte einfach das nehmen, was für den Einsatzzweck am sinnvollsten ist. Eine Liste von tausend floats speichere ich als ASCII-Text. Eine Liste von 1048576 RGB-Werten speichere ich binär.