Unterschiede (Vor- und Nachteile) vom XML gegenüber Ini-Dateien

Anmerkung: bei xml kannst du auch einfache hochkommata als attributbegrenzer benutzen (aber nicht mischen). sonst stimmt natürlich alles

c.rackwitz

'(screen (identifier "Default Screen")
         (device "Geforce")
         (monitor "iiyama ProLite E1900S")
         (defaultdepth 24)
         (display (depth 24)
                  (modes (1280 1024)
                         (1280 960)
                         (1152 864)
                         (1024 768)
                         (800 600)
                         (640 480))))

http://steve.yegge.googlepages.com/the-emacs-problem

Artchi

Hem, ich würde heute keines von beiden (ini oder xml) benutzen. Sondern würde auf eine Scriptsprache wie lua zugreifen. Die ist ideal dafür und ursprünglich sogar dafür entwickelt worden. ini und xml sind in meinen Augen bzgl. Configurationsleistungen (also was sie effektiv können) gleichwertig. Wobei ich xml für Config überhaupt nicht verstehen kann. Es ist nur formal "besser". xml halte ich für Datenaustausch zwischen unterschiedlichen Systemen und Anwendungen für sehr nützlich, mehr auch nicht.

Jedenfalls könnte man mit lua in der Config-Datei auch Bedingungen u.ä. einbauen. Z.B. wenn eine bestimmte Bildschirmauflösung nicht vorhanden ist, wird eine andere gewählt. Sowas müsste man ohne scriptsprache im C++-Programm vorhersehen bzw. einbauen. Die Möglichkeiten der Configuration würden auch autom. steigen. Bei XML und INI ist es immer stur, der Anwender kann eigentlich nichts viel bewirken, außer Attribute ändern. Einen Wirklichen Einfluss hat er mit beiden nicht. Deshalb halte ich die Diskussion Ini vs XML für akademisch.

darthdespotism

Also wenn hier für einige XML schon zu schwehr zum Parsen ist, eine Skripsprache ist sicher nicht leichter.

Meiner bescheidenen Meinung nach hat jede Version seine Berechtigung, je nachdem was ausgedrückt werden soll.

ini für nicht verschachtelte, einfache Configurationsdateien, XML wenn mehr struktur nötig ist und eine Skriptsprache wenn dynamik nötig ist.

In meinem aktuellen Projekt (2D-Spiel) werden sowohl ini als auch xml-files verwendet, im nächsten gibts dann auch Skriptunterstützung überall wos nötig ist.

Hallo,

Artchi schrieb:

Jedenfalls könnte man mit lua in der Config-Datei auch Bedingungen u.ä. einbauen. Z.B. wenn eine bestimmte Bildschirmauflösung nicht vorhanden ist, wird eine andere gewählt. Sowas müsste man ohne scriptsprache im C++-Programm vorhersehen bzw. einbauen. Die Möglichkeiten der Configuration würden auch autom. steigen. [...]

Prinzipiell hast du natürlich Recht, allerdings ist diese zusätzliche Flexibilität meiner Ansicht nach bereits eine Art Gratwanderung, denn letztendlich müsste ja sozusagen eine auf Plugins basierende Architektur vorhanden sein, um deinen Anforderungen gerecht zu werden. Ansonsten hat der Benutzer ja auch nur jene Möglichkeiten der Konfiguration, die ihm der Entwickler einräumt und eine derartige Modularisierung ist auch absoluter Overhead für die meisten Anwendungen.

Artchi schrieb:

Einen Wirklichen Einfluss hat er mit beiden nicht. Deshalb halte ich die Diskussion Ini vs XML für akademisch.

Es ging auch nie darum, wann dem Benutzer mehr Möglichkeiten eingeräumt werden, sondern (meiner Ansicht nach) wie sich die Möglichkeiten besser strukturieren lassen.

Ich persönlich verwende solch einfache Property Dateien (bzw. INI Dateien, oder wie auch immer man sie nennen mag) eigentlich nur für einfachste Schlüssel=Wert Zuweisungen, die sich konsequent durchziehen, wie beispielsweise Lokalisierungsdateien, die halt eine Nachricht in einer bestimmten Sprache enthalten.

# Messages_de_DE
hello_world=Hallo Welt

# Messages_en_US
hello_world=Hello World

Falls allerdings eine Sammlung von Konfigurationsoptionen benötigt wird, die nicht eine ähnlich starke Kohäsion aufweist, verwende ich eine eine XML Datei mit beispielsweise einzelnen Sektionen, die gegebenenfalls oben angeführte Property Dateien importieren.

Ich würde gleich alles in C++ Code speichern, da kannst da alles machen.

darthdespotism

KETRAXONTOR schrieb:

Ich würde gleich alles in C++ Code speichern, da kannst da alles machen.

Für einfache Programme vielleicht sinnvoll.

Aber:

Der User kann nichts anpassen
Nach jeder Anpassung muss der Quellcode neu compiliert werden
Modifizierungen (Fremdsprachliche Versionen ...) sind viel komplizierter als sie sein müssten
Andere können bestimmt andere Einschränkungen aufzählen
...

DEvent

schrieb:

# Messages_de_DE
hello_world=Hallo Welt

# Messages_en_US
hello_world=Hello World
Falls allerdings eine Sammlung von Konfigurationsoptionen benötigt wird, die nicht eine ähnlich starke Kohäsion aufweist, verwende ich eine eine XML Datei mit beispielsweise einzelnen Sektionen, die gegebenenfalls oben angeführte Property Dateien importieren.

Wie unterscheidest du ob hello_world nun _de_DE ist oder _en_US? Durch die Kommentare?
Grade dazu eignet sich XML doch super:

<sprachen>
    <item name="hellow_word" language="en_US">Hello World</item>
    <item name="hellow_word" language="de_DE">Hallo Welt</item>
</sprachen>

@c.rackwitz: genau das hat minhen gemeint. Einmal wird "" als Begrenzer eingesetzt, einmal nichts. Dann wird sogar no-name-Tags eingesetzt

(1280 1024)
(1280 960)
(1152 864)
(1024 768)
(800 600)
(640 480)

An dem Parser will ich nicht arbeiten wollen.

Regexps suck for processing XML.

Das wundert mich jetzt aber extrem. Ist das wahr und ich verstehe noch weniger von regexps als ich dachte?

Artchi

Wie unterscheidest du ob hello_world nun _de_DE ist oder _en_US? Durch die Kommentare?

Speichert man in unterschiedliche Dateien ab, somit ist eine Einteilung gegeben:

Dateien:
texte_de_DE.properties
texte_en_US.properties

Hat er nur nicht explizit angegeben. Bei Programmstart wird je nach locale die entsprechende Datei geladen.

Artchi schrieb:

Hat er nur nicht explizit angegeben. Bei Programmstart wird je nach locale die entsprechende Datei geladen.

Danke, dass du das ergänzt hast. Ich dachte eigentlich, dass es klar ist, aber ich hätte wohl im Code Block explizit die Dateiendung anführen sollen, um die letzten Zweifel restlos zu beseitigen.

c.rackwitz

DEvent:
lern scheme, dann wirst du merken, warum mein beispielcode sinn macht.
code und daten sind potentiell das gleiche. die daten koennen sich selbst "ausfuehren". modes z.b. koennte seine argumente eben so interpretieren. kein thema. kannst du mit xml nicht.

rexen und xml suckt, weil rexen und ungeparster quellcode suckt. deswegen gibts refactoring tools mit code-awareness. die schnibbeln nicht einfach nur am text rum, die sind sich der semantik bewusst. rexen sind sich der semantik hinter spitzen klammenr und slashes (=xml) nicht bewusst.

z.b. koennen rexen keine rekursiven klammernpaare matchen. geht nicht. dazu brauchst du was maechtigeres als rexen: z.b. PEGs oder normales BNF. sind eigentlich auch nur rexen, aber mit rekursion. und die brauchst du um rekursion zu matchen.
alle baumstrukturen sind inherent rekursiv. deswegen kannst du mit rexen da nix gross ausrichten.

scheme/lisp parser sind mit die einfachsten parser fuer irgendeine sprache die es gibt. und wenn du erstmal einen hast, dann hast du nicht nur einen config parser, du hast potentiell ein ganzes scripting system.

lies doch einfach mal, was der stevey da geschrieben hat. und lern scheme. mit "sicp" und "plt scheme". ist wichtig. glaub mir.

ernsthaft. lern scheme.

hustbaer

Weils hier gerade inetwa dazupasst: kennt jmd. denn eine gute XML Library für C++? Wobei "gut" im Sinne von einfach zu verwenden -- muss nicht allen Schnickschnack können, Validierung etc. bräuchte ich alles nicht.
Das Interface sollte halt einfach und halbwegs modern sein, also wenn geht mit std::string/wstring arbeiten etc. - keine Zeiger zurückgeben die man selbst löschen muss etc.

SideWinder

hustbaer schrieb:

Weils hier gerade inetwa dazupasst: kennt jmd. denn eine gute XML Library für C++? Wobei "gut" im Sinne von einfach zu verwenden -- muss nicht allen Schnickschnack können, Validierung etc. bräuchte ich alles nicht.
Das Interface sollte halt einfach und halbwegs modern sein, also wenn geht mit std::string/wstring arbeiten etc. - keine Zeiger zurückgeben die man selbst löschen muss etc.

TinyXML

MfG SideWinder

minhen

DEvent schrieb:

Grade dazu eignet sich XML doch super:

<sprachen>
    <item name="hellow_word" language="en_US">Hello World</item>
    <item name="hellow_word" language="de_DE">Hallo Welt</item>
</sprachen>

Da bietet sich aber xml:lang als Attribut schon an. Bei einer Aufteilung in eine Sprache pro Datei würde ich auch xml:id verwenden und sowas hier basteln:

<strings xml:lang="de_DE">
    <s xml:id="1001">Hallo Welt</s>
    <s xml:id="1002">Servus</s>
</strings>

Oder wenn's unbedingt in einer Datei sein soll auch sowas hier:

<strings>
    <string xml:id="1001">
        <s xml:lang="de_DE">Hallo Welt</s>
        <s xml:lang="en_US">Hello World</s>
    </string>
</strings>

Wenn man's in XML macht, sollte man schon die Standard-Attribute verwenden, wenn man deren Semantik meint. Hat einfach auch den Vorteil, dass eventuelle Editoren und sonstige Tools dann bereits automatisch wissen, was du meinst.

Regexps suck for processing XML.

Das wundert mich jetzt aber extrem. Ist das wahr und ich verstehe noch weniger von regexps als ich dachte?

Nein, ist nicht wahr.
Als "Beweis der Einfachheit" habe ich mir gestern nachmittag einen Parser für XML in Perl geschrieben. Und da hab ich selbstverständlich auch auf die regulären Ausdrücke von Perl zurückgegriffen. Das Ausgabeformat ist ein Hash, der Code ist also ein "Mapping" eines XML-Dokuments auf eine Standard-Datenstruktur von Perl. (Perl kennt drei Datenstrukturen: Skalare, Arrays und besagten Hash.)
Der Parser verarbeitet beliebig verschachtelte Tags korrekt, hat keine Probleme mit gemischtem Inhalt (Zeichendaten und Tags gemischt auf einer Ebene), verwurschtelt die ach so bösen Attribute korrekt und weil's so schön ist erkennt und verwendet er sogar die in der internen DTD definierten Standardwerte für Attribute.
Arbeitsaufwand: ungefähr 40 Zeilen Programmcode.
Der Code ist relativ simpel und besteht letztlich aus 5 regulären Ausdrücken. Ohne denen müsste es sich eigentlich auch brauchbar mit einem einfachen Kellerautomaten lösen lassen. Zwar ist der Parser nicht konform im Sinne der XML-Spezifikation, da er sich nur brauchbaren Kram heraussucht und z.B. keinerlei Fehlermeldungen ausspuckt, er ist auch kein Performancewunder, aber das soll er auch gar nicht sein. Es ging ja nur darum, dass XML eben doch nicht unglaublich schwer zu verarbeiten ist - selbst wenn man keinen der unzähligen existierenden Parser verwenden will. Eine Sprache, für die ich mir in kürzester Zeit ohne großem Nachdenken einen Parser aus dem Ärmel schütteln kann, finde ich nun wirklich nicht schwer zu parsen.

DrGreenthumb

SideWinder schrieb:

hustbaer schrieb:

Weils hier gerade inetwa dazupasst: kennt jmd. denn eine gute XML Library für C++?

TinyXML

TinyXML++ ist besser.

.filmor

DEvent schrieb:

<sprachen>
    <item name="hellow_word" language="en_US">Hello World</item>
    <item name="hellow_word" language="de_DE">Hallo Welt</item>
</sprachen>

Und warum benutzt du nicht xml:lang?!
Mal im Ernst, sowas schreibt doch kein Mensch freiwillig. Haufenweise inhaltsleerer Datenµll (item, name, language, /item, sprachen, /sprachen). Und selbst wenn man sich ein besseres Dateiformat ausdenkt, was ja durchaus möglich ist, ist das ganze für Menschen immernoch schwer zu bearbeiten.
Mehrere primitive Dateien und gut ist. Oder noch besser, was Fertiges wie gettext benutzen.

DEvent schrieb:

Regexps suck for processing XML.

Das wundert mich jetzt aber extrem. Ist das wahr und ich verstehe noch weniger von regexps als ich dachte?

Naja, eigentlich sind reguläre Ausdrücke doch per Definition nicht für Klammersprachen geeignet...

c.rackwitz

minhen schrieb:

Regexps suck for processing XML.

Das wundert mich jetzt aber extrem. Ist das wahr und ich verstehe noch weniger von regexps als ich dachte?

Nein, ist nicht wahr.
Als "Beweis der Einfachheit" habe ich mir gestern nachmittag einen Parser für XML in Perl geschrieben.

es gibt nen unterschied zwischen "parser bauen mit regexen" und "mit regexen xml zerlegen". regex ist kein xpath, xquery, etc.

minhen

.filmor schrieb:

DEvent schrieb:

Regexps suck for processing XML.

Das wundert mich jetzt aber extrem. Ist das wahr und ich verstehe noch weniger von regexps als ich dachte?

Naja, eigentlich sind reguläre Ausdrücke doch per Definition nicht für Klammersprachen geeignet...

Falsch. Reguläre Ausdrücke wie sie bei Programmiersprachen meistens implementiert sind, sind echt und deutlich mächtiger als Typ-3-Grammatiken. Das trifft besonders auf die regulären Ausdrücke von Perl zu - aber auch auf alle Implementierungen, die sich an Perl oder an der POSIX Extended Syntax orientieren. Und das sind praktisch alle Implementierungen. Egal ob bei PHP oder Boost für C++.
Das Grundmuster um Tags damit sinnvoll erkennen zu können, sieht so aus:
<(name)...> ... name ist dabei ein Teilausdruck, der gültige Namen für Tags gemäß XML-Spezifikation erkennt. Die runden Klammern drumherum halten den so erkannten Namen als erstes Teilergebnis (in der Variabel $1) fest. Der wichtige Punkt ist jetzt \1, was schlicht eine Backreference auf den Teilausdruck in $1 ist. Jetzt noch auf die Greediness achten und fertig ist ein regulärer Ausdruck, der zu einem beliebigen öffnenden Tag das passende schließende Tag (und alles was dazwischen steht) findet. Wie gesagt, ziemlich einfach und überhaupt kein Thema. Das Werkzeug "regulärer Ausdruck in der realen Welt" muss man dafür aber durchaus kennen

.filmor

Mir ist durchaus bewusst, dass man mit Perl-RegExes solche Sachen machen kann, aber nochmal, reguläre Ausdrücke an sich können keine Klammersprachen implementieren. Und nur, weil ihnen das mit derartigen Erweiterungen gelingt, heißt das nicht, dass sie dafür geeignet wären. Was macht dein Parser eigentlich, wenn man ihm Fehler unterjubelt?

minhen

.filmor schrieb:

Mir ist durchaus bewusst, dass man mit Perl-RegExes solche Sachen machen kann, aber nochmal, reguläre Ausdrücke an sich können keine Klammersprachen implementieren. Und nur, weil ihnen das mit derartigen Erweiterungen gelingt, heißt das nicht, dass sie dafür geeignet wären.

Wie bereits angedeutet, reguläre Ausdrücke der theoretischen Informatik und reguläre Ausdrücke in Programmiersprachen sind zwei paar Schuhe. Es geht hier - wie ebenfalls schon gesagt - nicht alleine um Perl. Sachen wie Backreferences beherrschen praktisch alle Implementierungen. PHP, Pyhton, Perl, Java - und das sind rein zufällig auch die regulären Ausdrücke, die man meint, wenn man vom Verwenden von regulären Ausdrücken einer Sprache spricht

Den letzten Satz musst du allerdings erklären. Die geforderte Aufgabe gelingt zwar einwandfrei mit regulären Ausdrücken aber reguläre Ausdrücke sind dennoch grundlegend nicht dafür geeignet? Alles klar ...

Was macht dein Parser eigentlich, wenn man ihm Fehler unterjubelt?

Steht bereits im entsprechenden Beitrag.