Diskussion:Dreierregel (C++)

C#

Die Bemerkung über C# ist falsch. Es gibt in C# weder Kopierkonstruktoren, noch Zuweisungsoperatoren, noch (im C++-Sinne) Destruktoren. Die Wurzel des Irrtums liegt im Ausdruck "andere objektorientierte Sprachen". Die Dreierregel hat mit Objektorientierung nichts zu tun. -- jens (nicht signierter Beitrag von 93.232.39.57 (Diskussion | Beiträge) 19:04, 15. Apr. 2010 (CEST))

Sehe ich auch so - ich habe es entfernt. --NeoUrfahraner 12:39, 18. Jun. 2010 (CEST)

in vielen Fällen nicht ausreichen

Mir sind zwei Dinge am Artikel aufgefallen: "...dass compilergenerierte Funktionen in vielen Fällen nicht ausreichen...". Das ist natürlich eine Frage des Designs. Ich würde sogar soweit gehen und behaupten, dass wenn man es für nötig hält, für einen Großteil seiner Klassen eigene Kopierkonstruktoren, Zuweisungsoperatoren und Destruktoren zu schreiben, man etwas falsch macht. Das scheint auch hier durchzuscheinen: "...Beispielsweise wenn die Klasse aus Objekten anderer Klassen zusammengesetzt ist, welche ausschließlich von ihr verwendet werden (Komposition). Die compilergenerierte Variante kopiert nur die Zeiger auf die Objekte (shallow copy)...". Wer sagt denn, dass man hier nur Zeiger für Komposition verwenden kann? Im Gegenteil! Man sollte den Spieß umdrehen und nur Zeiger als Datenelemente verwenden, falls wirklich nötig! Es gibt im Prinzip drei Objekt<->Objekt Beziehungen:

• Objekt A kennt Objekt B über ein Zeigerelement. B ist aber logisch gesehen kein Teil von A. (Beispiel: Iteratoren verweisen auf andere Objekte)
• Objekt B ist logisch gesehen Teil von Objekt A, wird aber von A aus nur indirekt über einen Zeiger erreicht. (Beispiel: std::vector und seine Elemente)
• Objekt B ist logisch und physikalisch ein Teil (Subobjekt) von A. (Beispiel: std::pair mit Elementen first und second)

Im ersten und letzten Fall, wobei der letzte Fall die Regel sein sollte, sind keine benutzerdefinierten Funktionen für das Kopieren, Zuweisen und Zerstören notwendig. Hier machen die vom Compiler generierten Funktionen genau das richtige. Nur im zweiten Fall ist es notwendig, weil man eine "besteht-aus"-Beziehung manuell über "kennt-ein" emuliert und dementsprechend die Kopiersemantik angepasst werden muss. -- 77.8.175.238 11:07, 23. Mai 2010 (CEST) Sebastian

Deine Analyse ist richtig; der Fall zwei ist es, bei dem die Dreierregel benötigt wird. Nur ist der Fall zwei nicht per se schlechtes Design. Dein Beispiel std::vector oder das en:pimpl-Idiom zeigen ja, das Fall 2 auch bei sauberem Design häufig auftritt. Es stimmt allerdings, dass der Artikel diesbezüglich ein wenig irreführend ist; vielleicht findet sich jemand, der das besser darstellen kann. --NeoUrfahraner 12:50, 18. Jun. 2010 (CEST)

Einleitungssatz misslungen

"Die Dreierregel bezeichnet in der Programmiersprache C++ eine Faustregel, die empfiehlt, dass eine Klasse, die eines der folgenden drei Elemente definiert, auch die jeweils anderen beiden definiert werden sollten." Der letzte Teil hängt in der Luft, als ob ein Wort fehlt, etwa "dass wenn" oder so. Grüße --Flusswehrwolf (Diskussion) 18:49, 17. Okt. 2015 (CEST)

gudn tach!

wurde mittlerweile (irgendwann) korrigiert. -- seth 18:37, 8. Sep. 2020 (CEST)