Ich hoffe mir kann jemand helfen.

Na egal, du musst den Speicher anscheinend wieder freigeben.
Jetzt fragt man sich nur wie der Speicher alloziert wurde.

Entweder mit new[] dann delete[] oder mit malloc und free.

Der Memory fault kam, weil ich den Index für den Zugriff auf ein Attribut zu groß gewählt war und damit außerhalb des Bereiches lag.

mfg chuqa

Funktionen die dir speicher allokieren, sollten zumindest nen gegenstueck zum aufraeumen, also ne eigene free funktion anbieten. Da du ja nicht wissen kannst, wie die Bib den speicher allokiert hat (und 25 mal in ne Doku schreiben iss so nen ding)

Standard ist eher, den user selber genug Speicher allokieren lassen und die bib schreibt dir nur auf den speicher ... damit kannst dann selber waehlen wie den speicher anlegst.

Also wenn die lib dir nen free() vorschreibt, wuerd ich designtechnisch die finger von lassen ...

"beruehmte" Ausnahmen sind zum beispiel die QT ... aber da wird es auch bei jeder gelegenheit bemaengelt ^^ (obwohl das an der stelle viele vorteile bringt fuer die QT)

Ciao ...

Signature for a free() implementation.

Nun habe ich doch noch eine Frage: Sollte nicht beim Aufruf der Variable, nachdem ihr Speicher mit free() freigegeben wurde, ein Fehler kommen, bzw. ihr Inhalt gelöscht also NULL sein?
dazu folgender Code:

xmlChar *name = xmlTextReaderGetAttributeNo(reader, 0);
cout << "Name : " << name << endl;
free(name);
cout << "nochmal Name: " << name <<endl;

Kompiliere und führe ich das aus so steht nach dem Aufruf der free-Funktion, dasselbe wie davor.

mfg chuqa

Da war ja irgendwas auf der Seite, lad dir das runter und benutze es

Edit: Das mit dem Problem kann ich mir nur so erklären: free() gibt ja den Speicher frei, d.h. aber noch lange nicht das er auch die Speicherstelle löscht bzw. mit irgend etwas anderm füllt
Die Stelle ist jetzt nur nicht mehr reseviert und kann folglich auf von anderen Resourcen benutzt werden ...

ein free sagt deinem BS nur, das es den speicher wieder selber nutzen darf, es anderen aufrufern etc zur verfuegung stellen darf .

Nur im debug modus werden so "kranke" sachen gemacht, wie den speicher mit nem muster ueberschreiben um zu checken ob da jemand unitialisiert drauf zugreift etc ...

im release wird da aus gruenden der performance sicher gar nix gemacht, da kann, muss aber nicht, noch stundenlang der alte wert drinnestehen ...

Ciao ...

Den C++-Wrapper würde ich glatt benutzen, nur die Ziel-PCs, auf denen das Programm laufen wird, benutzen die libxml2 und nicht libxml++.

mfg chuqa

wenn dir das zuviel aufwand ist, dann programmier halt mit c schnittstellen, iss halt nich so komfortabel

Ciao ..

Es gibt in verschieden anderen Headerfiles Funktion die allokierten Speicher wieder freigeben, z.B. gibt es in xmlmemory.h eine funktion xmlFreeFunc(void *mem). Als Erklärung steht dazu:

Signature for a free() implementation.

Da würde ich vermutlich diese Funktion zur Freigabe verwenden - wie Freak_Coder sagte, kannst du dir nicht sicher sein, welche Heap-Verwaltung die Lib verwendet; und wenn der Autor irgendwann von malloc()/free() auf new[]/delete[] umsteigt, haut's dir womöglich deine Programme um die Ohren.