Looks reasonable, but we don't want the architecture of the backend to affect the interface.
right. So what is would be reasonable semantics to expect from a dom API ? May be I'v just got used to libxml2's way of life, but I think it is a good choice. Nodes are owned by their parents, so you can do
dom::element *child = parent->add_child("info");
And calling
dom::element::iterator i = parent->find(child); parent->erase_child(i);
will invalidate 'child'. I don't know of any way to make that more safe while still being efficient.
There is also the problem that the user can be left with an invalid pointer after the document has been deleted.
Yes, but is that a problem ? Of course it has to be written in bold strokes: "Don't delete a document while operating on its content !",
but I think the main idea to get across is that nodes *can only* exist
in the context of a document. That's not only because of memory ownership issues, but also for a variety of other contextual data
associated with a node, such as namespaces.
I had a long discussion with the libxml2 author about ownership semantics and he convinced me that the current way is the best tradeoff between simplicity/ease of use and efficiency.
Since the DOM is a tree and has no cycles, it should be possible to get fairly close to the Java interface using strict ownership or shared_ptr underneath. In the libxml2 case every Node would need to keep the whole Document alive but this may not be necessary given a different backend.
I don't understand that. The document owns its nodes, so letting nodes reference the document would create loops, no ?
Of course if this isn't practical a quick fix would be to return a shared_ptr<Document> from parse_file.
yeah, that's unrelated. But why not std::auto_ptr then ?
Regards,
Stefan
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
