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