From: Hamish Mackenzie (hamish_at_[hidden])
Date: 2003-06-26 13:23:24
On Thu, 2003-06-26 at 18:32, Stefan Seefeld wrote:
> Hamish Mackenzie wrote:
> > On Thu, 2003-06-26 at 16:04, Stefan Seefeld wrote:
> >>I don't really understand why we need three different classes to
> >>manage documents. In particular I don't understand why you provide
> >>a 'document_ptr' that is a wrapper around document_ref.
> > The document_ref and document_ptr would only be used when a non owning
> > reference or pointer is required. Even then you could use
> > dom::document * and dom::document & instead in most cases.
> > One big difference between a reference and a pointer is that a reference
> > must contain a valid non null value.
> ok, but are these types really needed ?
> My current proposal only provides dom::document_ptr, and I use implicit
> refcounting on the underlying document tree. It seems to work quite
> fine. I provide a bool operator () that tells me whether the
> document_ptr is referring to a document or not.
I would rather have a debug version that tracked
pointers/iterators/references and flagged (at runtime) their use when
they are invalid. This could catch a wider range of problems including
the use of nodes who's parents have been erased.
> >>And I don't use a 'document' class, as that is managed implicitely
> >>by my dom::document_ptr:
> >>dom::document_ptr document; // create new document;
> >>dom::document_ptr doc(document); // create second reference to it
> >>dom::document_ptr doc2 = document.clone(); // clone it, i.e. make deep
> >> copy
> > This is not consistent with the standard library or C++ in general. It
> > will seem strange that the pointer class
> > 1) Does not require dereferencing
> would you say the same if the class name was spelled 'document_ref'
> instead ?
1 & 4 would be ok, but 3 would stand and having an 'operator bool' would
be added to the list.
> > 3) Has a constructor such as document_ptr( "config.xml" )
> > 4) Has member functions such as write_to_file
> > The alternative would allow both...
> > boost::shared_ptr< dom::document > doc( new dom::document() );
> > boost::shared_ptr< dom::document > doc1( doc );
> > dom::document doc2( *doc1 );
> > and if the 'doc1' reference was non-owning...
> > dom::document doc(); // Create new doc
> > dom::document & doc1( doc ); // Second reference
> > dom::document doc2( doc1 ); // Deep copy
> right, but given such an approach, what would nodes return in their
> 'parent()' method ?
The parent is always an element (is that right?) so it would return
element_ptr or element_ref.
I feel the correct answer is element_ptr, because, presumably,
root.parent() is null and you can't have a null reference.
You can apply the same logic to doc.root(). If a document can have a
null root then doc.root() should return a pointer. If it can't then it
should return a reference.
-- Hamish Mackenzie <hamish_at_[hidden]>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk