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 <[EMAIL PROTECTED]> _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost