http://lmgtfy.com/?q=c%2B%2B+xml+parser+library

Lg Tobi

Hier mal einige...
Simon

ticpp

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

..

Ok, das wusste ich nicht. Habe sie nie grossartig getestet. Fand einfach die Installation und Benutzung recht einfach.
Was empfiehlst du denn?

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

MfG,
ScRaT

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

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.

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.xml

Allerdings 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

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?

http://www.jezuk.co.uk/cgi-bin/view/arabica