copy constructor and assignment operator

[sajis997]

Hello forum,


In every class we create it is customary to create the copy constructor and assignment operator. If i derive from QObject do i have to define those copy constructor and assignment operator as well?


Regards
Sajjad

[SixDegrees]

You never need to implement these operators unless your class contains objects that require a deep copy. An array allocated with new(), for example, needs to be manually created and copied. On the other hand, if you use one of the STL container classes in the same role, you can simply accept the default operators provided by the compiler, since the STL classes are well behaved and handle copying themselves.

That said, QObjects generally don't play well with copy and assignment operators; their internal structure often abstracts away implementation details and makes it difficult to create a faithful copy. My advice is: don't do it. There's rarely a need.

[Santosh Reddy]

Just to add, QObejcts are not supposed to be copied by design. QObject is ID based and not value based. Refer (http://doc.qt.nokia.com/4.7-snapshot/object.html#identity-vs-value)

[squidge]

If i derive from QObject do i have to define those copy constructor and assignment operator as well?QObject does have both (including all Qt classes derived from QObject), but in a private section with the macro Q_DISABLE_COPY(). This is by design and the reason is explained above by other posters.

[sajis997]

Hello,

Thanks for the feed-back. In one of the Qt books i am following says that if i would like use QList for user defined class then there has to be copy constructor and assignment operator defined. But they did not mention anything what happens if the user-defined type is the subclass of QObject.



Regards
Sajjad

[Santosh Reddy]

If you want to store QObject based objects, then you need to store their pointers (and don't bother about the copy ctor and assignment operator for it), eg. QList<QObject*> (or QList<QObjectSubClass *>), all ID based class objects are to be stored (and passed around) this way.

[sajis997]

Hi

If i really do want to make a copy of an object which is in turn is a subclass of QObject, will it be possible through a generic function , for example clone() ?
I shall not be doing any copy constructor or assignment operator here.

Regards
Sajjad

[stampede]

You can implement clone() object for your QObject-based class, but how do you define a clone of QObject ? Should it have the same connections as base object ? What about its childrens ?
I guess it could be better (both by desing and code clarity) to define a Data class that represents and encapsulate every custom data you want to be copied, use it as a private member of your custom QObject class, and copy this data instead of whole object (which makes little sense IMHO).

[sajis997]

Hi

Let me explain why do i need to create a copy of an object. I have an editor which contains an widget holding node information of a database. It is a tree widget which contains the item. The user will be able to drag those tree item to another widget widget to do further processing. And the user may need to drag multiple copies from the same object.


The representation of the dragged node item is done using the subclass of the QGrpahicsItem and the representation of the node information is done using the subclass of the QObject. And to support multiple copies i need some kind of cloning of both of them.


Any suggestion to do it efficiently ?



Regards
Sajjad

[stampede]

What about creating a serialization methods for node data ? When entering the drag event you can store the dragged item data, for example, as xml string, and use this data to create and insert new node to dropped widgets. Thanks to that you can get away without explicit object copies (each drop "client" will create one for itself using serialized data).
Another thing, is QObject needed to only store some data ? Could you maybe use simple structures for this (this way object copying is provided out-of-the-box) ?