From: Stefan Seefeld (seefeld_at_[hidden])
Date: 2003-06-12 10:25:48
Peter Dimov wrote:
> 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");
dom::element::iterator i = parent->find(child);
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 ?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk