Kopydestruktor
-
Dann compilierst du mit den Falschen Optionen.
-
der link funktioniert nicht
und hier http://www.gotw.ca/publications/ habe ich den beitrag nicht gefunden (liegt aber wahrscheinlich an meiner unfähigkeit)kann mir jemand bitte erklären wo der sinn dahinter liegt? bzw. wie man es verwendet oder ein sinnvolles beispiel geben?
ich sehe den sinn leider nicht.
danke, schonmal
-
Wie würde denn ein Aufruf des Copydestruktors aussehen?
X* obj, obj2; ... delete obj(obj2);So vieleicht?
Und wie ist es wenn ich das Objekt nicht mit new erzeuge?
-
Original erstellt von Shade Of Mine:
kann mir jemand bitte erklären wo der sinn dahinter liegt? bzw. wie man es verwendet oder ein sinnvolles beispiel geben?wenn ich weit ausholen darf, ja.
es soll eigentlich um nen peer-destruktor gehen und die funktion terminate_peer. paare gibts oft, die immer gemeinsam leben und gemeinsam sterben sollen. seien es die beiden seiten eines über zwei rechner verteilten objekts. oder ein api-fenster-handle und bs-fester-handle.
doof ist, daß das abdere peer nicht automatisch stirbt, wenn das eine stirbt. naja, ist auch ein wenig schwierig, falls beide peers in unterschiedlichen threads hausen. aber egal. da tut irgendwie ein sprachmittel not.
wann ist das peer ne exakte kopie? zum beispiel bei spielen, wo nicht gemogelt werden darf. ich hab ne basisklasse
class Spieler { private: double elo; public: Zug machZug(Spielbrett const& brett); }und alle Spieler sollen davon erben.
Zwei Fehler.
Zug machZug(Spielbrett const& brett);
hier muß die referenz weg. sonst macht der böse gegner sowas:Zug machZug(Spielbrett const& brett) { Spielbrett& s=*const_cast<Spielbrett*>(&brett); s.removeQueen(); ... }das war noch kein großes problem. aber bei den spielern schaff ichs nicht, weil spieler nicht schnell kopierbar sind (immerhin merkt sich meiner die letzten 10^8 überlegten positionen oder sowas). und lass ich dem spieler sein echtes this, dann verfummelt der mit nem reinterpret_cast seine elo-punkte.
da denke ich irgendwie gleich an ne lösung mit nem echten spieler und ner kopie, die auf maagische weise syncron gehalten werden und auf magische weise zusammen leben und sterben.stimmt aber gar nicht mehr. ich dachte mal an sowas. aber heut nicht mehr. es sind inhaltlich ja gar nicht zwei spieler, die ich brauche, sondern nur ein spieler und sein eintrag in der elo-liste.
ups, trotz weit ausholen nix gewesen.
tja, wo braucht man ein objekt und seine genaue kopie, die zusammen sterben sollen?
-
Das war wohl ein April-Scherz von Marc++us!
-
Das ist kein Scherz !!
Hab jetzt gerade das Beispiel nicht zur hand,
aber es gibt sehr voll sinnvolle anwendungen des Kopydestructors.Devil
[ Dieser Beitrag wurde am 01.04.2003 um 13:43 Uhr von devil81 editiert. ]
-
Original erstellt von devil81:
**Das ist kein Scherz !!
Hab jetzt gerade das Beispiel nicht zur hand,
aber es gibt sehr voll sinnvolle anwendungen des Kopydestructors.Devil**
Dann könnte man doch auch beide hintereinander deleten??? Ist doch im Prinzip nix anderes
-
Original erstellt von MaSTaH:
Dann könnte man doch auch beide hintereinander deleten??? Ist doch im Prinzip nix anderesNicht im Prinzip.
So könnte man durch wiederholtes aufrufen des Kopykonstruktors eine
Liste Rekursiv löschen...Devil
-
Das ist kein Scherz !!
Ich meinte ja auch das von Marc++us. Bei dir kann ich das nicht beurteilen.
lirpa.htm -> april.htm
-
Original erstellt von devil81:
Nicht im Prinzip.
So könnte man durch wiederholtes aufrufen des Kopykonstruktors eine
Liste Rekursiv löschen...
Devildas geht aber doch bereits viel einfacher mit
template<class T> struct List { T head; List<T> *tail; ... ~List() { delete tail; } }
-
Alles Mumpitz.
-
Original erstellt von devil81:
**Hab jetzt gerade das Beispiel nicht zur hand, aber es gibt sehr voll sinnvolle anwendungen des Kopydestructors.
**dann nenn doch bitte eins.
falls es sich um nen april scherz handelt: bitte nicht in den fachforen! danke!
-
Original erstellt von devil81:
**Nicht im Prinzip.
So könnte man durch wiederholtes aufrufen des Kopykonstruktors eine
Liste Rekursiv löschen...Devil**
Selbst dann bräuchte man keinen Copy-Destruktor... Dann wäre eine Linked-List einfacher zu handhaben... Außerdem wurde ja von dem Löschen einer exakt gleichen Kopie (wofür auch immer man die braucht) gesprochen...
-
Ausserdem würde man die Kopie doch sowieso mit dem Copykonstruktor erstellen. Dann merkt man sich einfach einen Pointer auf das aktuelle Objekt in dem ursprünglichen Objekt und löscht dieses im Destruktor des Ursprungsobjektes falls es gesetzt wurde und nicht 0 ist...
[ Dieser Beitrag wurde am 01.04.2003 um 15:24 Uhr von MaSTaH editiert. ]
-
Original erstellt von MaSTaH:
Außerdem wurde ja von dem Löschen einer exakt gleichen Kopie (wofür auch immer man die braucht) gesprochen...nee, das war meine erfindung. vor mir wurde vom löschen eines objekts des selben typs (oder gar basisklasse) gesprochen.
-
Original erstellt von Shade Of Mine:
**dann nenn doch bitte eins.falls es sich um nen april scherz handelt: bitte nicht in den fachforen! danke!**
Das Forum gehört wohl Marcus, da hat er doch zu entscheiden wo April-Scherze gemacht werden und wo nicht. Und wenn er selbst einen macht, dann ist das auch okay so.
-
Original erstellt von Shade Of Mine:
falls es sich um nen april scherz handelt: bitte nicht in den fachforen!lol, wo denn sonst?
-
Nur damit keine Zweifel aufkommen.
Der Kopydestruktor ist natürlich ein Aprilscherz gewesen...
...und natürlich kenne ich auch keine sinnvolle Anwendung dessen
Und übrigens die ganze Sache auf meinem Mist gewachsen, nach dem ich mich
wieder mit Standard C++ und OOP beschäftige, trotzdem war die ergänzung von Marc++us
perfekt, da sich der Kopydestructor nicht kompilieren lässt (zumindest nicht unter
MSVC)
wäre interesant zu wissen was der C++ Standard dazu sagt ;),
aber seine Variante wohl durchgeht, ob wohl sie genauso wenig sinn macht... *g*naja, als Fazit bleibt
Interessant waren die Antworten dennoch...Devil
-
Machen wir den Thread lieber zu, sonst bekommen wir heute noch mehr Antworten.