2010-05-18 4 views
5

Ich weiß, dass Qobjects Identitäten nicht Werte sein sollen, zB können Sie sie nicht kopieren und standardmäßig sind der Kopierkonstruktor und die Zuweisung deaktiviert, wie in der qt Dokumentation erklärt. Aber ist es möglich, ein neues QObject mit Hilfe einer Clone-Methode aus einem bestehenden zu erstellen? Wäre das ein logischer Fehler? Wenn ich sageQObject Cloning

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

oder

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

und die Klon-Methode kopiert Sachen wie Mitglieder etc wäre dies falsch sein?

Und wenn das in Ordnung ist, kann ich meinen eigenen Kopierkonstruktor und Zuweisungsoperator schreiben, der genau das tut?

Hinweis: Ich möchte dies tatsächlich mit Klassen versuchen, die qobject erben.

+0

Dies würde auch die Verbindungen klonen? IMHO, es ist etwas falsch in Ihrem Code ... können Sie dies mit POD-Strukturen tun? – elcuco

+0

nein die Verbindungen müssen nicht nur die Datenelemente geklont werden, die im Objekt festgelegt sind (hauptsächlich die, die von der Vererbungsebene hinzugefügt wurden). – Olorin

Antwort

7

meiner Meinung nach QObjects Klonen fast immer semantisch gebrochen und führen zu unerwünschten Nebenwirkungen weil sie eine "Identität" haben, wie du schon gesagt hast. Daher bricht das Klonen alle Annahmen, die man über QObjects hat, wie ihre Signal/Slot-Verbindungen und dynamischen Eigenschaften. Sie sollten überlegen, ob die zu klonenden Objekte wirklich QObjects sein müssen, oder ob der "Wertteil", der geklont werden soll, ausgeklammert werden könnte.

Und wenn überhaupt, macht das Klonen nur Sinn für Ihre spezifischen Unterklassen von QObjects, nicht für QObjects selbst (die keine echten "wertähnlichen" Eigenschaften haben).

auch, A; B; A.cloneFrom (B) sieht fehlerhaft aus, da es nicht funktioniert, wenn B eine Instanz einer Unterklasse von B anstelle von B selbst ist. Clone sollte über eine virtuelle B * B :: clone() Const getan werden, würde ich sagen.

+3

Ich muss hinzufügen, dass ein häufiger Designfehler darin besteht, alles zu einem QObject zu machen, anstatt zweimal darüber nachzudenken. Ich mache nur QObjects wo notwendig, d. H. Wo das "Identitäts" -Muster gilt und ich brauche Signal/Slots etc. –

+0

Stimme völlig mit Frank überein. Sogar Qt selbst enthält viele Klassen, die nicht von QObject abgeleitet sind. Alle Wertcontainer wie QString, QList, QDomNode ... sind nicht von QObject abgeleitet. – VestniK

+0

Mein Fehler, wenn ich den Code schrieb, gab ich QObject als ein Beispiel die Vars sind nicht tatsächlich von Qobject Typ, aber der abgeleitete Typ sollte der Code sein MyClass a, b; b.cloneFrom (a); aber ich denke ich werde überlegen, eine Klasse nicht von qobject abgeleitet – Olorin

4

Ich denke, dass die beste Vorgehensweise in diesem Fall ist, eine Klasse mit den Daten zu erstellen, die Sie zwischen QObjects kopieren möchten. Diese Klasse sollte nicht von QObject oder einer von QObject abgeleiteten Klasse abgeleitet werden. Und diese Klasse wird "Wertbehälter" sein. In diesem Fall sollten Sie Ihr Problem wirklich gut lösen können.

Und noch ein Tipp: für diese Klasse können Sie mit Copy on Write impliziter Datenfreigabe verwenden Aufwand für unnötiges Kopieren zu reduzieren: http://doc.qt.io/qt-5/implicit-sharing.html