Re: [boost] API Review request: XML APIs for C++

From: Hamish Mackenzie (hamish_at_[hidden])
Date: 2003-06-13 08:31:06

On Fri, 2003-06-13 at 12:14, Peter Dimov wrote:
> Hamish Mackenzie wrote:
> >
> > 3) Why dom::basic_document::clone?  Why not have the copy constructor
> > and assignment operator should do a deep copy of the document?  This
> > is consistent with other containers. If you want to stick with clone
> > return
> > an auto_ptr and and derive basic_document from boost::noncopyable.
> 
> Whether clone is appropriate depends on the object model that we choose for
> Document and Node. One option is the Java-ish
> 

Only shallow copy if it is a pointer, iterator or reference.

So you would have to call them document_ptr, node_ptr, etc.  To make it
clear they are pointers.

> A safer Node alternative is
> 
> struct Node
> {
>     xmlNodePtr impl_; // or however it's spelled
> 
>     shared_ptr<document_impl> pi_; // keep Document alive
> };

But it won't prevent someone removing the root node from the document
and thereby invalidating all the document's nodes.  So it is a false
sense of security.

I can't see an easy way to implement a "node" type, but that's ok
because we don't need to....

What we need is a node_iterator which returns a node_proxy when
dereferenced (see the files attached to my second post).  node_proxy is
the reference_type of the container there would be no value_type
(perhaps node_reference would be a better name).

> Reference semantics are convenient when passing and returning Documents
> to/from functions. Documents can be deep copied with clone().
> 
> Another option is to drop the reference semantics. A Document can be
> noncopyable with clone(), mandating the use of auto_ptr, or it can have deep
> copy semantics.

Which is what I meant when I said...
> > If you want to stick with clone return
> > an auto_ptr and and derive basic_document from boost::noncopyable

But you have to ask yourself how would you feel if std::vector worked
this way?

> All of these solutions have their pros and cons, but other things being
> equal I tend towards the Java model. Deep copy seems inappropriate for a
> Document since it is a very expensive operation that's better given an
> explicit name. (I just found a bug in my code where I accidentally passed an
> expensive data structure by value; performance went downhill, I was
> stumped.)

It might be expensive for large documents (probably order N) but so is
std::vector's copy constructor.

How would you have felt if you had used an object believing it to deep
copy only to find out it didn't and as a result all the customer records
in your database ended up pointing to the same address value? 
shared_ptr< document > is easy to spot.

Shallow copy is for iterator, pointer and reference types only! It is
dangerous and should be written on the tin in bold print.

-- 
Hamish Mackenzie