Objekt im Speicher verschieben ; Speicherabbild erstellen

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.

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.

Dravere

Registrierter Troll schrieb:

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.

UTF-16 ist auch weit verbreitet, vor allem auch im asiatischen Raum, weil dort mit UTF-16 besser kodiert werden kann, bzw. mit weniger Speicherplatz. Zudem weisst du nie, wie das Textfile nun kodiert ist und ohne BOM kannst du das auch nicht einfach so herausfinden. Also musst du spezifieren, wie das Textfile gespeichert ist, also das Binärformat spezifizieren, dass kannst du aber genauso bei einem Binärfile machen. Somit ist man gleichweit.

Registrierter Troll schrieb:

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.

Ich verstehe nicht so recht. Wenn du jetzt das folgende meinst, dann bist du natürlich völlig auf dem falschen Dampfer:

fwrite(&myint, sizeof(myint), 1, file);

Natürlich geht das so nicht. Auch speichert man nicht ein struct einfach binär ab. Man verwendet ein binäres Format und wandelt die Daten zuerst entsprechend um. Dass musst du bei einem Unicode String aber auch tun, du musst es zuerst in UTF-8 oder was auch immer umkodieren. Ich sehe absolut keinen Unterschied.

Registrierter Troll schrieb:

Standardisieren kann man binäre Formate genauso wie Textbasierende, insofern ist das sowieso kein Argument.

Aber genau das ist mein Argument, dass es eben für beides Formate gibt und dass es eben kein Argument ist. Ich sage ja nicht, dass Binärformate gegenüber den Textformaten im Vorteil wären, sondern dass sie ebenbürtig sind!

Registrierter Troll schrieb:

Immerhin sind aber die Kodierungen standardisiert und weitestgehend portabel, bei Binärdaten sind schon einfach nur blanke Zahlen ein potenzielles Problem.

Die Aussage ist einfach nichts aussagend. Du sagst: Bei Text, wenn man ein Format definiert, ist es kein Problem. Bei Binärdaten, wenn man kein Format definiert, dann ist es ein Problem.
Merkst du nicht, wie unsinnig diese Aussage ist? Wenn man kein Format bei Text definiert, dann ist es genauso problematisch und umgekehrt.

Registrierter Troll schrieb:

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

Es geht mir ja nicht darum, was schwieriger ist. Ich sage beides hat die gleichen oder gleich viele Probleme. Text hat keine offensichtlichen Vorteile gegenüber Binärformate und auch umgekehrt nicht.

Registrierter Troll schrieb:

Security by obscurity ist ein sehr fragwürdiges Konzept

Funktioniert aber öfters als man meint, vor allem wo man keine grosse Sicherheit möchte. Nur damit nicht jeder DAU daran rumpfuschen geht

Registrierter Troll schrieb:

Man sollte einfach das nehmen, was für den Einsatzzweck am sinnvollsten ist.

Genau das ist auch meine Aussage. Und ich sage halt auch, dass man Binärdaten durchaus öfters in betracht ziehen sollte. Text wird überbewertet.

Grüssli

Registrierter Troll

Dravere schrieb:

Registrierter Troll schrieb:

Immerhin sind aber die Kodierungen standardisiert und weitestgehend portabel, bei Binärdaten sind schon einfach nur blanke Zahlen ein potenzielles Problem.

Die Aussage ist einfach nichts aussagend. Du sagst: Bei Text, wenn man ein Format definiert, ist es kein Problem. Bei Binärdaten, wenn man kein Format definiert, dann ist es ein Problem.
Merkst du nicht, wie unsinnig diese Aussage ist? Wenn man kein Format bei Text definiert, dann ist es genauso problematisch und umgekehrt.

Zunächst mal muss man zwischen Format und Kodierung unterscheiden. Ein Dateiformat ist die Definition einer Datenstruktur. Eine Kodierung definiert das Alphabet, aus dem die Struktur aufgebaut ist. Das Format einer Textdatei lautet zB. 1 Eintrag pro Zeile, Zeilenende ist \n. Die Kodierung ist ASCII.

Der String "3735928559\n" ist quasi universell verständlich, so ziemlich jedes System auf der Welt, von hier bis Süd-Peking, weiß ohne großen Aufwand etwas damit anzufangen. Man muss sich keine Kodierung dafür ausdenken und man muss sich auch keine Gedanken über Endianess machen, oder in welchen Datentyp man den String einliest. Das grundlegende Format ist offensichtlich, die Kodierung in der Regel standardisiert.
Jede Programmiersprache bietet fertige Mittel, mit diesen Daten umzugehen. Die größte Sorge dabei ist, wie das Zeilenende kodiert wird, oder ob man auch auf Exoten wie EBCDIC-Systemen damit arbeiten will.

Auf 0xdeadbeef10 trifft das nicht zu. Die Bedeutung variiert von System zu System.
Man muss Konventionen festlegen, in welcher Reihenfolge die einzelnen Octets zu interpretieren sind. Man muss bestimmen, wie floating point values kodiert werden. Vielleicht braucht man Trennzeichen - man muss also erst mal ein Alphabet erfinden. Und so weiter. Dazu kommt noch, dass man mitunter Text in den Binärdaten ablegen will, und dafür dann zusätzlich noch eine Kodierung festlegen muss.

Beide Vorgehensweisen mögen vom Ergebnis ebenbürtig sein. Binärdaten haben noch den Vorteil der besseren Effizienz.
Der Entwicklungsaufwand ist aber meiner Meinung nach bei Textdaten geringer. Außer wenn man für ein einziges System und einen einzigen Compiler entwickelt, dann sind Binärdaten bequemer.

Dravere

Registrierter Troll schrieb:

Der String "3735928559\n" ist quasi universell verständlich, so ziemlich jedes System auf der Welt, von hier bis Süd-Peking, weiß ohne großen Aufwand etwas damit anzufangen. Man muss sich keine Kodierung dafür ausdenken und man muss sich auch keine Gedanken über Endianess machen, oder in welchen Datentyp man den String einliest. Das grundlegende Format ist offensichtlich, die Kodierung in der Regel standardisiert.

Man muss sich keine Kodierung ausdenken <-> Die Kodierung ist in der Regel standardisiert? Ehm, wie jetzt? Und welche Kodierung nimmst du jetzt? Du musst dich festlegen. Es gibt viele Standards. Du vereinfachst hier masslos!
Keine Gedanken über Endianess ist auch schlicht gelogen, wie ich es schon mehrfach aufgeführt habe.
Dein String ist zudem nicht universell verständlich, du musst auch zusätzliche Definition dazustellen. Könnte ja auch eine Hexzahl oder Oktalzahl sein. Hier ist überhaupt nichts offensichtlich, du musst genau gleich viel definieren, damit die Schnittstelle funktioniert. Du stellst dir das viel zu einfach vor und übersiehst, dass du viele Dinge einfach als offensichtlich hinstellst, obwohl du sie genau gleich definieren musst.

Registrierter Troll schrieb:

Jede Programmiersprache bietet fertige Mittel, mit diesen Daten umzugehen.

Also gerade als C oder C++ Programmierer solltest du wissen, dass nicht jede Programmiersprache fertige Mittel anbietet. Und wenn du nun mit Libraries kommst, dann frage ich dich, wieso man nicht auch Libraries für Binärfiles verwenden kann, zum Beispiel wie bei SQLite?

Registrierter Troll schrieb:

Man muss Konventionen festlegen, ...

Ohne welche du auch kein Textfile lesen kannst, da legst du die auch fest!

Registrierter Troll schrieb:

Man muss bestimmen, wie floating point values kodiert werden. Vielleicht braucht man Trennzeichen - man muss also erst mal ein Alphabet erfinden. Und so weiter. Dazu kommt noch, dass man mitunter Text in den Binärdaten ablegen will, und dafür dann zusätzlich noch eine Kodierung festlegen muss.

Wie soll der Text abgespeichert werden? Wie soll die Syntax aussehen? Wird der Dezimalpunkt als Punkt oder Komma dargestellt? Wie wird ein Datum notiert? Du musst ganz genau bestimmen, wie es im Textfile passieren soll.

Du kannst natürlich ein Format nehmen, wo das bereits alles für dich erledigt wird, aber dass gibt es bei Binärformaten auch. Wie ich zum Beispiel schon mal sagte: SQLite.

Registrierter Troll schrieb:

Der Entwicklungsaufwand ist aber meiner Meinung nach bei Textdaten geringer.

Ja, es gibt einen Unterschied, wenn du nämlich eine Bibliothek für Textformate nimmst und mit dieser entwickelst, aber beim Binärformat zuerst die Bibliothek selber entwickelst. Logisch hast du dann einen Mehraufwand. Aber wenn du die Bibliothek für den Text auch selber implementierst, dann wäre es gleich, oder du nimmst beim Binärformat auch eine Bibliothek und es ist gleich.

Du vergleichst einfach nicht auf gleicher Ebene.

Grüssli

Registrierter Troll

Dravere schrieb:

Man muss sich keine Kodierung ausdenken <-> Die Kodierung ist in der Regel standardisiert? Ehm, wie jetzt? Und welche Kodierung nimmst du jetzt? Du musst dich festlegen.

Ich nehme ASCII. Oder UTF-8. Ich muss mir keine Kodierung ausdenken (natürlich im Sinne von erfinden!), weil es ASCII und UTF-8 als fertig standardisierte Kodierung schon gibt, und so ziemlich jedes System kann sie verarbeiten.

Keine Gedanken über Endianess ist auch schlicht gelogen, wie ich es schon mehrfach aufgeführt habe.

Ja, weil du ASCII und UTF-8 einfach ignorierst. Für die ist Endianess irrelevant. Wenn ich selbst festlegen kann, wie ich meine Dateien speichere, dann nehme ich natürlich das einfachste - darum geht es doch gerade, um Einfachheit. Wenn UTF-8 für die Aufgabe nicht ausreicht, wird es komplizierter. Das ist dann aber schon jenseits dessen, was ich hier propagiere.

Also gerade als C oder C++ Programmierer solltest du wissen, dass nicht jede Programmiersprache fertige Mittel anbietet.

Gut, jede war vielleicht übertrieben. Ich hätte aber Mühe eine Allzwecksprache zu finden, die keine Funktionen für das Lesen von ASCII-Files und das rudimentäre parsen selbiger mitbringt. C++ und C jedenfalls können das ganz gut. Welche relevante Sprache kann es denn nicht?

Und wenn du nun mit Libraries kommst, dann frage ich dich, wieso man nicht auch Libraries für Binärfiles verwenden kann, zum Beispiel wie bei SQLite?

Hab ich nichts dagegen gesagt. Es stellt sich natürlich die Frage, auf wie vielen Systemen SQLite verfügbar ist, und wie relevant die Portierbarkeit im Einzelfall ist.

Registrierter Troll schrieb:

Man muss Konventionen festlegen, ...

Ohne welche du auch kein Textfile lesen kannst, da legst du die auch fest!

Ja. ASCII. Mit \n getrennte Dezimalzahlen. Fertig. Kann von einer Unzahl von Systemen auf der Welt sofort gelesen und verarbeitet werden, ohne viel zu programmieren oder auf den SQLite-Port warten zu müssen.

Wie soll der Text abgespeichert werden? Wie soll die Syntax aussehen? Wird der Dezimalpunkt als Punkt oder Komma dargestellt? Wie wird ein Datum notiert? Du musst ganz genau bestimmen, wie es im Textfile passieren soll.

Du wirfst die ganze Zeit Kodierung (edit: Semantik) und Formatierung (edit: Syntax) durcheinander. Dass man die Formatierung in beiden Fällen definieren muss, ist doch klar. Es geht mir darum, dass alleine schon die Kodierung der Daten zwischen verschiedenen Systemen aufwendig synchronisiert werden muss. Ob eine Bibliothek das erledigt oder nicht, ist dabei doch völlig egal. Der Punkt ist, dass das mit Text in einer allgemein gültigen und portablen Kodierung einfacher sein dürfte als mit binären Codes. "1000" auf x Plattformen korrekt als 1000 zu interpretieren ist quasi immer eine triviale Aufgabe - das gleiche mit 0x03e8 zu tun ist eben nicht trivial.
Und selbstverständlich verwende ich dafür die Standard-Bibliotheken der Programmiersprachen, die mir die notwendigen Werkzeuge liefern - genau deshalb nehme ich ja überhaupt ASCII-Text. Weil es der kleinste gemeinsame Nenner ist.

Ja, es gibt einen Unterschied, wenn du nämlich eine Bibliothek für Textformate nimmst und mit dieser entwickelst, aber beim Binärformat zuerst die Bibliothek selber entwickelst. Logisch hast du dann einen Mehraufwand. Aber wenn du die Bibliothek für den Text auch selber implementierst, dann wäre es gleich, oder du nimmst beim Binärformat auch eine Bibliothek und es ist gleich.

Das ist richtig. Genau darum geht es. Ich will nicht selbst entwickeln, und wenn doch, so wenig Arbeit wie möglich haben. Text zu speichern und zu laden ist ein No-Brainer, sogar auf dem Mobiltelefon, das kein SQLite kennt.

Wie ist es denn nun mit dem Text in Binärdateien, der zusätzlich eine Kodierung braucht? Warum ist es deiner Ansicht nach genauso einfach, zwei Kodierungen zu verwenden statt nur einer?