Geek Answers Handbook

Copy constructor implementation

I have the following class definition, and it needs a copy constructor, so copies are made to copy the original pointers. Can anyone advise what is the best way to do this?

Using xerces-C ++ for XML

class XMLDocument { private: typedef std::vector<XML::XMLNode> v_nodes; public: XMLDocument::XMLDocument(); XMLDocument::XMLDocument(const XMLDocument& copy); XMLDocument::~XMLDocument(); XMLDocument& operator=(XMLDocument const& rhs); void CreateDocument(const std::string& docname); void AddChildNode(XMLNode& node); void RemoveNode(XMLNode& node); void AddNodeValue(XMLNode& node, const std::string& value); void AddNodeValue(XMLNode& node, int value); void AddNodeValue(XMLNode& node, double value); void AddNodeValue(XMLNode& node, float value); std::string GetXMLAttributes(); std::string GetXMLAttribute(const std::string& attrib); std::string GetXMLNodeText(XML::XMLNode& node); std::string DumpToString(); XMLNode GetXPathNode(const std::string xpathXpression); XMLNode GetNode(const XMLNode &currentnode); typedef v_nodes::iterator nodes_iterator; nodes_iterator begin() { nodes_iterator iter; iter = xmlnodes.begin(); return iter; } nodes_iterator end() { nodes_iterator iter; iter = xmlnodes.end(); return iter; } private: v_nodes xmlnodes; bool InitializeXML(); DOMImplementation* impl; //Abstract DOMDocument* document; //Abstract DOMElement* rootelement; //Abstract };

A DOMDocument is created with a function call and , and a DOMElement. So I can’t just call it a new pointer.

Not sure if I am literally recreating all these objects?

Example:

 document = impl->createDocument(0, "mydoc", 0);

Who went on a rage with a downward flow and did not receive a reason ???

+4
source share
5 answers

This page can certainly help:
http://icu-project.org/docs/papers/cpp_report/the_anatomy_of_the_assignment_operator.html

Note that this is the difference between writing a copy constructor and an assignment operator, but this point is also discussed in the article.

+2
source

Writing a copy constructor always does the “Right Thing” for each member variable. Without seeing the API documents for your DOMImplementation , etc., It’s hard to say that there will be a “Right Thing”. Perhaps they have a copy constructor or a function to create a deep copy. You may not need a deep copy semantically (e.g. for DOMImplementation ).

On the bottom line, it's hard to say without seeing the API docs that you obviously get around ...

Edit: So you are using Xerces-C. You did not tell us that before ...

Edit 2: Let's see, then ...

The Xerces-C API does not really provide any “easy” ways to copy a document object from what I see. AFAICT, you will need to create a completely new document ( impl->createDocument() ), and then manually copy all the attributes and child nodes.

It is so inconvenient that I would ask the question "why do I want to copy my XMLDocument object, one way or another? Does it even make sense at the semantic level?". (Personal experience: if something gets ugly when working with a well-used API, most likely you are doing something wrong, because otherwise it will be an easy way. XML is not my strong streak, so I'm not in my depth here .)

+2
source

Devsolar is right about copy constructors. Listen to his advice.

In addition, you really should not copy DOM structures. The standard procedure when I work with XML is to write a handler that receives data from DOM / SAX and creates its own object based on this structure. When you finish reading all the DOM / SAX elements, you had to construct in memory:

  • A data structure that contains all the necessary data from XML.
  • An object built from XML, but separable from XML. You are using this object in your application. Most likely, you will serialize this object in xml in the future.

This way you do not need to copy the DOM. Instead, you create your own objects to represent the data. Remember that you want to separate the application from XML. What if in the future you decide to use binary serialization?

+1
source

If you need deep copying using the library you are using, the path to it is to ensure that every member of the data member of your XMLDocument class knows how to copy itself (using its own copy constructor). And so on recursively for each type of data item. In practice, this means determining the types of removable shells from scratch.

Take care to determine exactly what belongs (for copying) and what does not (exists elsewhere and simply refers).

The main reason for this hierarchical packaging is that you want C ++ auto-destruction to succeed when some copying of a part fails. But it also greatly simplifies. And when you get down to the lowest levels of the components, you can get more detailed recommendations on copying such the smallest part.

Cheers and hth.,

+1
source

I would recommend a little review of the rules of ownership. If you want to make a deep copy, most likely you are trying to work around which variable owns the memory of other variables. In your case, it looks like you take care of every instance of XMLDocument that owns the v_nodes and DOM variables.

Another way to fix common problems is to transfer your instance variables to smart pointers.

That way, every time you copy the XMLDocument construct, you simply throw in the number of references to each of ivars. Each time a dtor is called for an instance of XMLDocument, the reference count is decremented. Essentially, you disable the lifetime of each instance of XMLDocument with its ivars. Instead, it is the reference number that belongs to it.

I am not an expert on xerces, but it is worth checking out various smart ptr implementations, for example. acceleration library.

0
source

More articles:


All Articles