Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!
Werbeanzeige
Ja. Nur sind das oft nicht die ausschlaggebenden Punkte. Zum Beispiel wird in einem Spiel die Performance durch Datei-IO-Operationen nicht relevant beeinträchtigt; die Priorität liegt woanders. Speicherverbrauch scheint mir in den meisten Fällen auch nicht wirklich ein Kriterium, da genügend Festplattenspeicher vorhanden ist und - wenn man sich geschickt anstellt und nur das Nötige speichert - auch recht wenig Speicher verbraucht wird. Ein int braucht dann zum Beispiel 7 statt 4 Byte. Bei anderen Dingen wie Strings verliert man hingegen gar nichts.Zitat von »"dot"«
Aber auch genauso Vorteile. z.B. ist es meist effizienter im Sinne von braucht weniger Speicherplatz und ist schneller zu lesen/schreiben.
Zitat von »"Nexus"«
Ja. Nur sind das oft nicht die ausschlaggebenden Punkte. Zum Beispiel wird in einem Spiel die Performance durch Datei-IO-Operationen nicht relevant beeinträchtigt; dieZitat von »"dot"«
Aber auch genauso Vorteile. z.B. ist es meist effizienter im Sinne von braucht weniger Speicherplatz und ist schneller zu lesen/schreiben.
Priorität liegt woanders.
Zitat von »"Nexus"«
Speicherverbrauch scheint mir in den meisten Fällen auch nicht wirklich ein Kriterium, da genügend Festplattenspeicher vorhanden ist und - wenn man sich geschickt anstellt und nur das Nötige speichert - auch recht wenig Speicher verbraucht wird. Ein int braucht dann zum Beispiel 7 statt 4 Byte. Bei anderen Dingen wie Strings verliert man hingegen gar nichts.
Zitat von »"Nexus"«
Die Nachteile würde ich trotzdem nicht unterschätzen.
Ich sage nicht, dass binäres Schreiben grundsätzlich schlecht ist. Es gibt natürlich berechtigte Anwendungsfälle, zum Beispiel wenn Dinge wie Performance tatsächlich relevant sind oder ein 1:1-Abbild erwünscht ist. Aber im Normalfall - insbesondere für Anfänger - rate ich zu einem flexibleren Format, speziell wenn etwas über längere Zeit und auf mehreren Compilern/Plattformen verwendet werden soll.
- Portabilität ist nahezu unmöglich.
- Grösse der Datentypen
- Alignment/Padding
- Big/Little Endian
- Zahlenrepräsentation, z.B. durch Zweierkomplement
- Binäres Schreiben ist nur im Zusammenhang mit POD-Typen möglich, also sehr eingeschränkt in C++. Hingegen arbeiten die Stream-Operatoren objektorientiert und können ganze Klassen einlesen oder ausgeben.
- Anfälliges Hantieren mit Zeigern und Speicherbereichen, undefiniertes Verhalten kann sehr schnell entstehen (natürlich kein Argument, wenn man genau weiss, was man tut - aber generell fehleranfälliger).
- Schlechte Debugmöglichkeiten, zum Beispiel kann man seine Daten nicht anschaulich im Text-Editor betrachten.
- Textdateien können nicht weiterverwendet werden, wenn sich am Aufbau der Klasse etwas ändert.
Hm, da hast du Recht. Ich habe jetzt eher an einfache Spielstände gedacht. Bei komplexen Landschaften etc. wäre vielleicht ein Kompromiss angebracht: Für die Portabilität existiert ein entsprechendes Format (muss nicht XML sein), bei einer Anwendung mit einer spezifischen Konfiguration wird das einmalig umgewandelt und in ein effizientes Binärformat gebracht. So kann man die Vorteile beider Möglichkeiten kombinieren.Zitat von »"dot"«
Das würd ich absolut nicht behaupten. Wie gesagt es hängt stark davon ab was du speicherst. Wenn es darum geht ganze Landschaften in Echtzeit aus Dateien zu streamen sind riesige Datenmengen im Spiel und Textdateien absolut fehl am Platz...
Das mag zwar sein - Fakt ist aber, dass all diese Probleme und der nötige Aufwand zu deren Behebung gar nicht erst entstehen, wenn ein flexibles Format eingesetzt wird. Du triffst hier auch relativ viele Annahmen. Es braucht nicht allzu viel, bis eine von diesen nicht mehr erfüllt ist, und du hast wieder Probleme. Probleme, an die du ohne binäres Schreiben gar nicht erst denken musst.Zitat von »"dot"«
Die Portabilität ist ein Problem, allerdings muss man auch hier relativieren.
Klar, aber damit entfernt man sich aber wieder vom Vorteil, mehrere Dinge auf einmal auszugeben (manche Leute benutzen diesen Punkt als Argument für binäres Schreiben). Der Aufwand kommt dem eines portablen Formats nahe. Unter Umständen geht Performance durch zusätzliche Überprüfungen/Umwandlungen wieder verloren.Zitat von »"dot"«
Weiters hindert dich niemand dran das binäre schreiben/lesen von komplexeren Objekten zu kapseln (von mir aus auch in einem überladenen << operator)
Die Probleme, die man debuggen muss, resultieren zu einem Teil aber auch aus den Fehlern, welche durch das Pointerhantieren entstanden sind. Klar, ein Fortgeschrittener sollte solche Fehler nicht mehr machen. Tatsache ist, dass es trotzdem immer Fehler gibt, und rohe Zeiger haben nun mal ein gewisses Fehlerpotential. Das kann eingeschränkt werden, indem man eine gewisse Kapselung einbringt. Aber zumindest in diesem Forum habe ich noch nie jemanden gesehen, der das wirklich durchzieht. Im besten Fall wird reinterpret_cast statt C-Casts verwendet...Zitat von »"dot"«
das bisschen hantieren mit Zeigern was dazu nötig ist sollte eigentlich jeder der über den Status eines Anfängers hinaus ist im Schlaf beherrschen. Natürlich sind Binärdateien nicht so anschaulich wie Textdateien und sicher aufwendiger zu debuggen, aber mit einem einigermaßen brauchbaren HEX Editor ist auch das kein größeres Problem.
Zitat von »"Nexus"«
Hm, da hast du Recht. Ich habe jetzt eher an einfache Spielstände gedacht. Bei komplexen Landschaften etc. wäre vielleicht ein Kompromiss angebracht: Für die Portabilität existiert ein entsprechendes Format (muss nicht XML sein), bei einer Anwendung mit einer spezifischen Konfiguration wird das einmalig umgewandelt und in ein effizientes Binärformat gebracht. So kann man die Vorteile beider Möglichkeiten kombinieren.Zitat von »"dot"«
Das würd ich absolut nicht behaupten. Wie gesagt es hängt stark davon ab was du speicherst. Wenn es darum geht ganze Landschaften in Echtzeit aus Dateien zu streamen sind riesige Datenmengen im Spiel und Textdateien absolut fehl am Platz...
Zitat von »"Nexus"«
Das mag zwar sein - Fakt ist aber, dass all diese Probleme und der nötige Aufwand zu deren Behebung gar nicht erst entstehen, wenn ein flexibles Format eingesetzt wird. Du triffst hier auch relativ viele Annahmen. Es braucht nicht allzu viel, bis eine von diesen nicht mehr erfüllt ist, und du hast wieder Probleme. Probleme, an die du ohne binäres Schreiben gar nicht erst denken musst.Zitat von »"dot"«
Die Portabilität ist ein Problem, allerdings muss man auch hier relativieren.
Zitat von »"Nexus"«
Klar, aber damit entfernt man sich aber wieder vom Vorteil, mehrere Dinge auf einmal auszugeben (manche Leute benutzen diesen Punkt als Argument für binäres Schreiben). Der Aufwand kommt dem eines portablen Formats nahe. Unter Umständen geht Performance durch zusätzliche Überprüfungen/Umwandlungen wieder verloren.Zitat von »"dot"«
Weiters hindert dich niemand dran das binäre schreiben/lesen von komplexeren Objekten zu kapseln (von mir aus auch in einem überladenen << operator)
Zitat von »"Nexus"«
Die Probleme, die man debuggen muss, resultieren zu einem Teil aber auch aus den Fehlern, welche durch das Pointerhantieren entstanden sind. Klar, ein Fortgeschrittener sollte solche Fehler nicht mehr machen. Tatsache ist, dass es trotzdem immer Fehler gibt, und rohe Zeiger haben nun mal ein gewisses Fehlerpotential. Das kann eingeschränkt werden, indem man eine gewisse Kapselung einbringt. Aber zumindest in diesem Forum habe ich noch nie jemanden gesehen, der das wirklich durchzieht. Im besten Fall wird reinterpret_cast statt C-Casts verwendet...Zitat von »"dot"«
das bisschen hantieren mit Zeigern was dazu nötig ist sollte eigentlich jeder der über den Status eines Anfängers hinaus ist im Schlaf beherrschen. Natürlich sind Binärdateien nicht so anschaulich wie Textdateien und sicher aufwendiger zu debuggen, aber mit einem einigermaßen brauchbaren HEX Editor ist auch das kein größeres Problem.
C-/C++-Quelltext |
|
1 2 3 4 |
file.write(reinterpret_cast<const char*>(&width), sizeof(width)); file.write(reinterpret_cast<const char*>(&height), sizeof(height)); file.write(reinterpret_cast<const char*>(&bits), sizeof(bits)); file.write(reinterpret_cast<const char*>(&descriptor), sizeof(descriptor)); |
Zitat von »"Nexus"«
Natürlich ist ein solches gekapseltes Binärformat durchaus vorteilhaft. Aber was ich so gesehen habe, wollen teilweise selbst fortgeschrittene Programmierer 1:1 roh binär schreiben und erhalten undefiniertes Verhalten, weil sie sich der Gefahren nicht bewusst sind. Vielleicht auch, weil sie sich zu wenig mit essentiellen Grundlagen von C++ befasst haben. Von diesem Standpunkt aus halte ich es für geeigneter, zuerst ein flexibles Format (muss nicht XML sein, Textdateien reichen schon recht weit) zu probieren. Dann zeigt sich immer noch, ob binäres Schreiben besser geeignet ist. Denn in sehr vielen Fällen spielen Geschwindigkeit und Speicherverbrauch eben doch nicht die grösste Rolle, wohl aber Sicherheit und Lauffähigkeit des Programms. Ganz nach dem Prinzip der Premature Optimization.
C-/C++-Quelltext |
|
1 2 3 4 5 |
template <typename T> void write_binary(const T& obj) { m_file.write(reinterpret_cast<const char*>(&obj), sizeof(obj)); } |
Werbeanzeige