2010-05-18 12 views
5

So che i Qobject devono essere identità non valori, ad esempio non è possibile copiarli e, per impostazione predefinita, il costruttore e l'assegnazione delle copie sono disabilitati come spiegato nella documentazione qt. Ma è possibile creare un nuovo QObject da uno esistente usando un metodo clone? Questo sarebbe un errore logico? Se dicoQObject cloning

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

o

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

e la roba metodo Clone copie come membri ecc questo sarebbe sbagliato?

E se questo è ok posso scrivere il mio costruttore di copia e l'operatore di assegnazione che fa proprio questo?

Nota: in realtà voglio provare questo con classi che ereditano qobject.

+0

Questo clonerebbe anche le connessioni no? IMHO, c'è qualcosa di sbagliato nel tuo codice ... puoi rifarlo con le strutture del POD? – elcuco

+0

no le conections non devono essere clonate solo i membri di dati che sono impostati nell'oggetto (principalmente quelli aggiunti dal livello di ereditarietà). – Olorin

risposta

7

a mio parere clonazione QObject è quasi sempre semanticamente rotto e porta a effetti collaterali indesiderati , perché hanno una "identità" come hai già detto. Pertanto, la clonazione interrompe tutte le ipotesi su QObjects, come le loro connessioni segnale/slot e le proprietà dinamiche. Dovresti considerare se gli oggetti da clonare devono davvero essere QObjects, o se la "parte di valore" che vuoi clonare potrebbe essere scomposta.

E, in caso affermativo, la clonazione ha senso solo per le sottoclassi specifiche di QObjects, non per gli oggetti QObjects stessi (che non hanno proprietà "value-like" reali).

anche, A; B; A.cloneFrom (B) sembra danneggiato, in quanto non funziona se B è l'istanza di una sottoclasse di B invece di B stessa. Il clone dovrebbe essere fatto tramite un const B * B :: clone() virtuale direi.

+3

Devo aggiungere che un errore di progettazione comune è quello di rendere tutto un QObject invece di pensarci due volte prima di farlo. Creo QObjects solo laddove necessario, cioè dove si applica il modello "identità" e ho bisogno di segnale/slot ecc. –

+0

Totalmente d'accordo con Frank. Anche Qt stesso contiene molte classi che non sono derivate da QObject. Tutti i contenitori di valori come QString, QList, QDomNode ... non sono derivati ​​da QObject. – VestniK

+0

Il mio male quando ho scritto il codice ho dato a QObject come esempio i vars non sono in realtà di tipo qobject ma del tipo derivato il codice dovrebbe essere MyClass a, b; b.cloneFrom (a); ma penso che prenderò in considerazione l'utilizzo di una classe non derivata da qobject – Olorin

4

Penso che in questo caso sia la procedura migliore per creare una classe con i dati che si desidera copiare tra QObjects. Questa classe non dovrebbe essere derivata da QObject o da alcuna classe derivata da QObject. E questa classe sarà "value container". In questo caso dovresti essere in grado di risolvere il tuo problema in modo davvero buono.

Un ultimo suggerimento: per questa classe è possibile utilizzare la condivisione di dati implicita con copia su scrittura per ridurre il sovraccarico di copiare inutili: http://doc.qt.io/qt-5/implicit-sharing.html

Problemi correlati