Copy-Assignment-Operator bei dereferenzierten Objekten
-
Artchi schrieb:
Solltest du auch in deinen nächsten Artikel irgendwie mit einbringen.
Ich werd das Thema mal mit auf meine Ideenliste setzen für kommende Operator-Artikel
-
pumuckl schrieb:
Die Sache ist allgemein relativ kompliziert, wie auch in http://icu-project.org/docs/papers/cpp_report/the_assignment_operator_revisited.html dargestellt wird.
Was genau ist da kompliziert?
Das Gebiet ist doch bereits vollstaendig erforscht, oder?
Oder uebersehe ich irgendwas?
-
Wäre das ne Alternative für dich ? :
// Dummy Code: class base { int dummy; virtual base& assign(const base &b); public: base(); base(const base &b); base& operator=(const base &b) { assign(b); } virtual ~base(); }; class special : public base { int dummy2; virtual special& assign(const base &b) { /* downcast hier sicher! */ } public: special(); special(const special &s); special& operator=(const special &s) { base::operator=(s); assign(s); } };
-
KasF schrieb:
Wäre das ne Alternative für dich ? :
Nein!
-
Shade Of Mine schrieb:
Nein!
Anworte vernünftig oder unterlasse in Zukunft deine Antworten auf meine Beiträge !
-
Shade Of Mine schrieb:
Was genau ist da kompliziert?
Zu entscheiden welche Nachteile man in Kauf nehmen will und welche Vorteile/Features man wirklich braucht. Es gibt halt keine "best practice"
-
pumuckl schrieb:
Shade Of Mine schrieb:
Was genau ist da kompliziert?
Zu entscheiden welche Nachteile man in Kauf nehmen will und welche Vorteile/Features man wirklich braucht. Es gibt halt keine "best practice"
Mhm...
Wenn man Reference Typen kopieren will braucht man eine clone Semantik und die kann der op= nicht bieten...Sprich:
Polymorphes Verhalten? entweder nicht kopierbar oder clone-like verhalten.
Value Typen Verhalten? entweder nicht kopierbar oder über op= kopierbar.
Dann gibt es nur noch die Spezialsituation mit Collections die ja über ein Basisinterface ansprechbar sind und anhand dessen kopiert werden können. Das geht hier, da eine Collection ja keine daten hinzufügt...
-
KasF schrieb:
Wäre das ne Alternative für dich ? :
Ganz pragmatisch und funktioniert. Super!
-
hustbaer schrieb:
also entweder du verzichtest darauf basisklassen-zeiger oder -referenzen für eine klassen zu verwenden.
oder du verzichtest darauf die klasse kopierbar zu machen.funktioniert in der praxis erstaunlich gut (heisst: es gibt kaum fälle, wo man beides bräuchte)
Hem, ich habe in meiner Library tatsächlich alles mit dynamisch erzeugten Objekten zu tun, die alle in Smart-Pointern verwaltet werden. Für Objektübergaben in Funktionen und Return-Objekten brauche ich das tatsächlich keine Kopien und Zuweisungen. Deshalb bisher von mir auch nicht implementiert.
Wäre eine Überlegung wert einfach das ganze private zu setzen, da es nicht gerade wenig Objekte sind, wo ich das implementieren muß.
-
@Artchi: ja, genau. Oder einfach von boost::noncopyable ableiten.
Im Prinzip ist das was ich geschrieben habe dasselbe wie Shade nochmal später geschrieben hat, nur etwas anders formuliert.
Auf jeden Fall sollte man entweder einen passenden Copy-Ctor + Assignment-Operator implementieren (wenn dies möglich und sinnvoll ist), oder die Klasse "noncopyable" machen (d.h. Copy-Ctor und Assignment-Operator "private" machen, bzw. von z.B. boost::noncopyable ableiten, was dazu führt dass Copy-Ctor und Assignment-Operator nicht vom Compiler erstellt werden können).
