"Swap Trick" und konstante Objektvariablen
-
??????? schrieb:
Die Konstanten zu vertauschen hätte ja auch unglaublich viel sinn.
ja ganz bestimmt
-
Die Klasse hat selbstverstaendlich noch unglaublich viel zusaetzliche dynamische Speicherverwaltung zu erledigen, hab ich bloss rausgelassen
Der operator= soll dann so aussehen:
Rect &Rect::operator=(const Rect &rhs) { Rect tmp(rhs); rhs.Swap(*this); return *this; }
-
imo müsste da dein Compiler Jaulen.
wegen dem const im parameter. // Vielleicht auch nicht
// Edit:
Wie sieht denn dein Copy C'tor aus?
-
Klar jault der Compiler, die Frage war ja ob es in diesem Fall noch einen anderen "Trick" gibt. Ich denke ich werde die constness einfach wegcasten.
-
kann man nicht für die konstanten die Initialisierungsliste des Copy-Konstruktors nehmen und für den Rest der Variablen den Swap-Trick?
-
Gunnar schrieb:
Rect &Rect::operator=(const Rect &rhs) { Rect tmp(rhs); //macht das sinn? rhs.Swap(*this); //hier müsste doch tmp.Swap(*this) stehen.... return *this; //dann müsste es funktionieren, oder nicht? }
-
Ich würde einfach width und height non const und private machen. Dann würde ich public getter Methoden zur Verfügung stellen.
-
@leech: Danke, war ein Abtipfehler.
@plan: Das geht nicht, denn ich will zwei Instanzen vertauschen, erstelle mir aber nur eine (die Temporaere).
-
Gunnar schrieb:
@plan: Das geht nicht, denn ich will zwei Instanzen vertauschen, erstelle mir aber nur eine (die Temporaere).
Was bringt dir das:
Rect tmp(rhs);
Denn wenn du es dann überhaupt net benutzt?
-
beschreib nochmal genau dein probem...
du hast eine klasse rect, die 2 const int hat...(und noch mehr sachen)
du hast eine funktion swap und brauchst einen copykonstruktor und den zuweisungsoperator überladen...habe ich das soweit richtig verstanden?
-
leech schrieb:
Gunnar schrieb:
Rect &Rect::operator=(const Rect &rhs) { Rect tmp(rhs); //macht das sinn? rhs.Swap(*this); //hier müsste doch tmp.Swap(*this) stehen.... return *this; //dann müsste es funktionieren, oder nicht? }
ja, es macht sinn.
der trick an der sache ist, dass Swap keine exceptions werfen darf. wenn im copy ctor eine exception geworfen wird, so bleibt das objekt für welches der op= aufgerufen wurde in einem konsistenten zustand,da zu dem zeitpunkt noch keinerlei änderungen durchgeführt wurden, es darf also weiter benutzt werden.
-
jaja, den trick kenne ich... das "macht das sinn?" bezog sich auf das erstellen des objekts, wenn dieses gar nicht benutzt wird...
gibt es nicht noch einen trick bei dynamischer speicherverwaltung?
damit alles korrekt aufgeräumt wird, weist man doch dem temp objekt die adresse des aktuellen objekts zu, damit beim verlassen der destruktor aufgerufen wird und die alten daten des aktuellen objekts aufgeräumt werden... das vertauschen geht dann über eck mit einer hilfsvariablen...
-
Hallo,
die Frage hat imo eigentlich nichts mit swap zu tun (das ist nur ein Implementationsdetail). Die Frage die du dir stellen solltest ist, was bedeutet kopieren/zuweisen für ein Objekt mit konstanten Membern?
Sollte auf diese Frage die Antwort lauten, dass kopieren und zuweisen eine jeweils andere Bedeutung haben (durchaus wahrscheinlich), dann ist Copy-and-Swap nicht sinnvoll, da Copy-and-Swap darauf beruht, dass Kopieren und Zuweisung semantisch äquivalent sind.
-
Du meinst, Objekte mit Wertesemantik sollten generell keine const-Member besitzen?
Die Constness bei meinen Problem kam eigentlich daher, dass ab dem Erstellen (und bis zu einer neuen Wertzuweisung via operator=) bestimmte Groessen nicht aenderbar sein sollten. Konkret die Groesse eines Bauteils in einer Karte, weil die Groessenaenderung nicht vorgesehen ist (und viel zu viel Programmieraufwand waere).
Dann waere die constness also falsch?