XML parsen
-
Hallo, für ein Projekt bin ich gezwungen einige XML-Dokumente zu parsen
Da meine Vorkenntnisse auf dem Gebiet ohnehin gegen 0 gehen, wollte ich fragen ob ihr eine möglichst einfache Bib kennt die mir dabei hilft.
-
-
http://rapidxml.sourceforge.net/
http://www.grinninglizard.com/tinyxml/
http://expat.sourceforge.net/Hier mal einige...
Simon
-
-
drakon schrieb:
Rate ich dringend davon ab!
Die Speicherverwaltung ist miserable gelöst darin. Wenn du zum Beispiel über 3000 Nodes iterierst, dann wird in jedem Iterationsschritt neuer Speicher allokiert und dem vorherigen zur Verwaltung übergeben. Dadurch hast du am Ende der Iteration (am Ende des Blocks) eine rekursive Speicheraufräumung von 3000 Schritten. Der Stackoverflow lässt freundlich grüssen
Grüssli
-
Dravere_logoff schrieb:
..
Ok, das wusste ich nicht. Habe sie nie grossartig getestet. Fand einfach die Installation und Benutzung recht einfach.
Was empfiehlst du denn?
-
drakon schrieb:
Was empfiehlst du denn?
Keine ... leider.
Als ich eine gebraucht habe, waren sie entweder zu gross und umständlich oder dann klein und schlecht programmiert. Wobei TinyXML damals noch die Nase weit vorne hatte. Es ist zwar kein schönes C++ und auch ist sie nicht so wahnsinnig schnell, aber man kann einigermasen vernünftig damit was realisieren.Schlussendlich hatte ich damals eine eigene XML Bibliothek geschrieben und verwendet.
Von RapidXML habe ich erst später was gehört und bisher nur gutes. Kann selber aber halt kein Urteil dazu abgeben, müsste ich zuerst mal testen.
Grüssli
-
Wie ist den XmlLite von Microsoft?
Hat damit schon jemand hier gearbeitet?MfG,
ScRaT
-
Dravere_logoff schrieb:
Die Speicherverwaltung ist miserable gelöst darin. Wenn du zum Beispiel über 3000 Nodes iterierst, dann wird in jedem Iterationsschritt neuer Speicher allokiert und dem vorherigen zur Verwaltung übergeben. Dadurch hast du am Ende der Iteration (am Ende des Blocks) eine rekursive Speicheraufräumung von 3000 Schritten. Der Stackoverflow lässt freundlich grüssen
bin zwar jetzt mit der suche auf diesen tollen hinweis gekommen, jedoch frage ich mich, ob das problem noch immer vorhanden ist oder ob dies damals so war als du xml libs getestet hast (falls dieser test schon länger her ist?)
wie kann man das überprüfen ob dies noch immer so ist? wenn man ein 100mb xml file die nodes einfach durchläuft ?!danke
lg johannes
-
tinyxml (und ticpp) ist nicht wirklich besser geworden. Vor allem ticpp hat einige Passagen, in denen arge Perfomanceeinbußen hingenommen werden (iteration über alle children und dabei Testen per dynamic_cast, ob der Typ auch zum Template-Parameter passt., z.B.)
rapidxml ist nicht schlecht, wenngleich recht minimalistisch, dafür wie vieles von boost eine reine Header-lib. Noch dazu ist es die einzige die ich kenn, die einem den char-Typen wählen lässt (template halt).
Ich verwende muttlerweile pugixml. Bietet eigentlich eine recht umfangreiche Schnittstelle um sich durch den DOM-Tree zu hangeln (z.B. find_child_by_attribute).
Außerdem bietet es XPath, was das Holen einer Node auf einen einzigen Funktionsaufruf beschränkt (schau mal bei wikipedia).
Es gibt auch iteratoren, wenn man das braucht.
-
Ich kann die Qt-XML-Klassen empfehlen, aber das wird sich wohl nur lohnen wenn man eh schon mit Qt entwickelt, ansonsten sind die Abhängigkeiten die man sich damit einkauft viel zu groß.
-
Ich hatte da mal einen kleine Vergleich geschrieben...
http://lars.ruoff.free.fr/xmlcpp/
-
taff schrieb:
Dravere_logoff schrieb:
Die Speicherverwaltung ist miserable gelöst darin. Wenn du zum Beispiel über 3000 Nodes iterierst, dann wird in jedem Iterationsschritt neuer Speicher allokiert und dem vorherigen zur Verwaltung übergeben. Dadurch hast du am Ende der Iteration (am Ende des Blocks) eine rekursive Speicheraufräumung von 3000 Schritten. Der Stackoverflow lässt freundlich grüssen
bin zwar jetzt mit der suche auf diesen tollen hinweis gekommen, jedoch frage ich mich, ob das problem noch immer vorhanden ist oder ob dies damals so war als du xml libs getestet hast (falls dieser test schon länger her ist?)
Ist schon länger her, habe daher kurz in den aktuellen TiCpp Code geschaut, aber scheint immer noch genau gleich zu laufen mit der Speicherverwaltung. Das erstellte Wrapper-Objekt wird dem vorherigen Wrapper-Objekt zur Verwaltung übergeben. Und erst wenn das Parent-Wrapper Objekt zerstört wird, werden die anderen Wrapper Objekte rekursiv im Destruktor der Reihe nach zerstört. Bäm.
taff schrieb:
wie kann man das überprüfen ob dies noch immer so ist? wenn man ein 100mb xml file die nodes einfach durchläuft ?!
Ich habe damals dieses File durchlaufen:
http://wiretap.wwiionline.com/xml/facilitylist.xmlAllerdings war es in einer Anwendung drin, dass heisst, dass bereits etwas Speicher vom Stack verwendet wurde. Also wenn man es direkt von der main aus macht, könnte es vielleicht funktionieren. Ist ja auch das heimtückische an diesem Fehldesign. Es fällt erst bei wirklich grossen Sachen auf. Und der Fehler kommt einem auch noch am Ende eines Blockes entgegen geflogen, nämlich dort, wo die Destruktoren aufgerufen werden. Da ist man sehr froh, wenn man weiss, wie ein Debugger und Callstack zu verwenden ist.
Grüssli
-
super danke für die vielen antworten!
das heißt also zusmamengefasst, wenn man tinyxml verwenden möchte/soll, dann sollte man tinyxml direkt verwenden ohne dem ticpp-wrapper?!
es ist so, dass ich pyhton code habe den ich quasi in c++ unter linux nachbilden muss/möchte und dieser code verwendet tinyxml und da war mein gedanke, dass ich dies genau so mit tinyxml realisiere der einfachheit halber. soll ich das dann auch tun in euren augen oder auf ein stärkeres pferd ala rapidxml (oder was anderes einfach+schlankes) setzen?
-
Schau dir mal Arabica an, damit kannst du zwischen verschiedenen vollwertigen XML Parsern wechseln.
Du musst dich halt entscheiden, benötigst du vollen XML Support, oder reichen dir parser wie pugi/rapidxml, welche zum Teil keine Namespaces oder Validierung können.
