Objekt im Speicher verschieben ; Speicherabbild erstellen
-
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
structeinfach 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
-
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
0xdeadbeef10trifft 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.
-
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
-
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?
