2010-05-18 5 views
5

Je sais que les Qobjects sont censés être des identités et non des valeurs, par exemple vous ne pouvez pas les copier et, par défaut, le constructeur et l'affectation de copie sont désactivés comme expliqué dans la documentation qt. Mais est-il possible de créer un nouveau QObject à partir d'un QObject existant en utilisant une méthode clone? Serait-ce une erreur de logique? Si je disQObject cloning

QObject b; 
QObject a; 
b.cloneFrom(a); 

ou

QObject a = new QOBject(); 
QObject b = new QOBject(); 
b->cloneFrom(a); 

et la substance des copies de méthode clone comme des membres, etc serait-ce mal?

Et si cela est correct, puis-je écrire mon propre constructeur de copie et opérateur d'affectation qui fait exactement cela?

Note: Je veux vraiment essayer ceci avec des classes qui héritent de qobject.

+0

Cela permettrait également de cloner les connexions non? À mon humble avis, il y a quelque chose qui ne va pas dans votre code ... pouvez-vous refaire cela avec des structures POD? – elcuco

+0

non les connexions n'ont pas besoin d'être clonées uniquement les membres de données qui sont définis dans l'objet (principalement ceux ajoutés par la couche d'héritage). – Olorin

Répondre

7

à mon avis, le clonage QObjects est presque toujours sémantiquement cassé et conduit à des effets secondaires indésirables , parce qu'ils ont une "identité" comme vous l'avez déjà dit. Par conséquent, le clonage brise toutes les suppositions que l'on a à propos de QObjects, comme leurs connexions signal/slot et leurs propriétés dynamiques. Vous devriez considérer si les objets à cloner doivent vraiment être QObjects, ou si la "partie-valeur" que vous voulez cloner pourrait être factorisée.

Et si c'est le cas, le clonage n'a de sens que pour vos sous-classes spécifiques de QObjects, pas pour les QObjets eux-mêmes (qui n'ont pas de vraies propriétés de type "valeur").

également, A; B; A.cloneFrom (B) a l'air brisé, car cela ne fonctionne pas si B est l'instance d'une sous-classe de B au lieu de B elle-même. Le clonage devrait être fait via un B * B :: clone() virtuel je dirais.

+3

Je dois ajouter qu'une erreur de conception commune est de faire de tout un QObject au lieu de penser deux fois avant de le faire. Je ne fais que QObjects où c'est nécessaire, c'est-à-dire où le modèle "identité" s'applique et j'ai besoin de signaux/slots etc. –

+0

Totalement d'accord avec Frank. Même Qt lui-même contient beaucoup de classes qui ne sont pas dérivées de QObject. Tous les conteneurs de valeur comme QString, QList, QDomNode ... ils ne sont pas dérivés de QObject. – VestniK

+0

Mon mauvais quand j'ai écrit le code que j'ai donné QObject à titre d'exemple les vars ne sont pas réellement de type qobject mais du type dérivé le code aurait dû être MyClass a, b; b.cloneFrom (a); mais je pense je vais envisager d'utiliser une classe non dérivée de qobject – Olorin

4

Je pense que la meilleure pratique dans ce cas de créer une classe avec les données que vous souhaitez copier entre QObjects. Cette classe ne doit pas être dérivée de QObject ou de toute classe dérivée de QObject. Et cette classe sera "conteneur de valeur". Dans ce cas, vous devriez être en mesure de résoudre votre problème de manière très efficace.

Un conseil: pour cette classe, vous pouvez utiliser le partage de données implicite avec copie à l'écriture à réduire les frais généraux de copie inutile: http://doc.qt.io/qt-5/implicit-sharing.html

Questions connexes