From: Stefan Seefeld (seefeld_at_[hidden])
Date: 2003-06-26 07:55:24
Hamish Mackenzie wrote:
> On Wed, 2003-06-25 at 20:45, Stefan Seefeld wrote:
>>>Why should the node-wrappers keep the document alive?
>>for consistency, and convenience. In the same way you can get down from
>>the document to the individual nodes you can get up: node.parent() and
>>node.document() provide the means to walk up towards the document root.
> And yet it does not keep it's parent() alive. How is that consistent?
> In what way would you be unable to walk toward the document if it was
> not add reffed?
dom::document_ptr = document("foo.xml");
root = document.root_node();
at this point document would go out of scope and so the tree would
be destructed, making root invalid. With root holding a reference
to the document it is not, and the following will work:
dom::document_ptr document = root.document();
// continue here...
> With the implicit add ref it is hard to tell what the intent of the code
> is. Your example illustrates this problem well, but consider this
> simpler version....
yes, letting the user explicitely manage the document would be the alternative.
I'm not sure that nodes referencing their document is less clear, though.
> xml::document_ptr doc( "config.xml" );
> some_function( doc->root_node() );
> I cannot tell what the writer intended the scope of doc to be without
> examining some_function and understanding what it does. It might add
> ref the document it might not.
What about the relationship between the document and dom::document_ptr ?
So even if 'doc' (a document pointer) is limitted, the callee could
set its own member
my_doc = node->document()
and just by looking at the API it is not clear that the 'doc'
variable above is really the master document pointer. Being
able to write things like
somehow suggests that either the document is not managed by
dom::document_ptr at all, or by all of them (and thus by
extension by dom::node_ptr)
>>>Here is the analogy I think works best...
>>>container --> document
>>>container::value_type --> node
>>>container::iterator --> node_iterator
>>>container::pointer_type --> node_pointer
>>>container::reference_type --> node_reference
>>hmm, that makes it look simpler than it actually is: is there really
>>a single 'value_type' ?
> True you need attribute_, element_ etc. variations which you already
> value_types could exist but it would require a deep copy to be
> consistent. If you do want to define it then I suggest
you mean if I do *not* want to define it ?
> typedef void value_type;
> Your iterator types look good. Why is there an extra level of
> indirection in basic_element_const_iterator?
the const iterator is non-functional right now. I'v been wondering
how to provide one. It seems I would need to define a 'const_node_ptr'
set of classes.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk