Boost logo

Boost :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2003-06-13 06:14:05

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

Document d = parse_file("test.xml");
Node n = d.root();

with Document and Node having reference semantics. Internally Document could

struct Document
    shared_ptr<document_impl> pi_;

and Node could be

struct Node
    xmlNodePtr impl_; // or however it's spelled

A safer Node alternative is

struct Node
    xmlNodePtr impl_; // or however it's spelled

    shared_ptr<document_impl> pi_; // keep Document alive

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.

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

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