Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at