Re: [boost] API Review request: XML API for C++, second round

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 ?

IMHO yes

> 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]>