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@[...].uk> 

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost