spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Xml macht Sinn, sobald man hierarchische Daten hat. Ansonsten kann man auch einfach ini-Dateien nehmen oder ein eigenes Textdateiformat definieren, wenn man nicht so viele Features braucht.
Textdateien sind halt größer, können aber auch "per Hand" editiert werden und man kann Fehler besser erkennen. Außerdem hat man in der Regel keine Probleme mit unterschiedlichen Binärdarstellungen (Reihenfolge und Anzahl an Bits für ein Int, z.B.) auf verschiedenen Plattformen.
Nachteil ist natürlich, dass sie etwas größer sind und damit komplexer zu verarbeiten. Und für manche Dinge eignen sie sich einfach schlecht, z.B. um Bilddateien zu speichern.

Und ja: VOn tinyXml ist dringend abzuraten, weil ticpp einfach moderner und robuster ist. Kannst natürlich auch einen der vielen anderen Xml Parser benutzen.

@Fred: danke für den Tipp sieht gut aus.

Zitat von »Jonathan_Klein«

Xml macht Sinn, sobald man hierarchische Daten hat. Ansonsten kann man auch einfach ini-Dateien nehmen oder ein eigenes Textdateiformat definieren, wenn man nicht so viele Features braucht.
Textdateien sind halt größer, können aber auch "per Hand" editiert werden und man kann Fehler besser erkennen. Außerdem hat man in der Regel keine Probleme mit unterschiedlichen Binärdarstellungen (Reihenfolge und Anzahl an Bits für ein Int, z.B.) auf verschiedenen Plattformen.

Das klingt fast so, als wären XML-Dateien keine Textdateien.
Man kann auch in XML-Dateien hervorragend Bilddateien speichern. Base 64 ist da das Stichwort.

Der Tipp mit TiCpp ist Klasse! Danke!

Ja klar, man kann ein Xml-Node machen mit einer riesig langen Zeichenkette, die dann halt Base64 oder sonstwie kodiert ist. Aber mal ehrlich, ist das noch eine Xml Datei? Ich meine, es ist natürlich sinnvoll, kleiner Binärdatensätze so in eine XML-Datei einzubetten, aber sobald der Anteil an Binärdaten zu groß wird sollte man das ganze IMO noch einmal hinterfragen.

Achja: Man ist bei XML natürlich nicht auf normale Textdateien beschränkt (obwohl das wohl die Regel ist), sondern kann sie auch zum Beispiel in zip.Archive packen (so wie odt das macht, zum Beispiel). Dann hat man trotzdem relativ kompakte Dateien, nur das auslesen ist natürlich minimal langsamer, sonstige Vorteile wie die Robustheit bleiben aber weiterhin bestehen. Und man kann so etwas mit geeigneter Abstraktion natürlich sehr leicht ein/ausschalten.

XML Vorteil wird auch schnell mal zum Nachteil. Bei XML kann das Verhältnis "eigentliche Information" zu "Overhead" ganz schnell sehr ungünstig werden. Vorallem rate ich aus persönlicher Erfahrung davon ab relationale Datensätze in XML verwalten zu wollen. Eine mögliche Alternative zu XML wo das Verhältnis Information:Overhead deutlich besser ist, ohne dass die Übersichtlichkeit deutlich leidet, ist json.

Zitat von »Checkmateing«

[...]
Was machen eigentlich die Anderen? Sagen die: Programm wurde mit X vielen Dateien zusammen geöffnet? [...]

z.B. Photoshop kannst du mit mehreren Dateien gleichzeitig öffnen, die du dann alle bearbeiten kannst. So musst du nicht jede Datei einzeln öffnen...

int main(int argc, char* argv[]) heißt das.

argc gibt an, wie viele Elemente argv hat. argv[0] ist immer der Pfad, wo sich das Programm selbst befindet und argv[1] ist der Pfad zur Datei, falls eine Datei mit dem Programm geöffnet werden soll.

jep, denn das c bei argc steht für counter, also argument counter, und das v bei argv für value -> argument values