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