Copy Constructor
-
huhu ihrs,
mein Prof. meinte, dass der Copy Constructor vom Compiler keine Referencen und Konstanten kopiert, und man immer einen eigenen Copy Constructor schreiben müsse, wenn man Konstanten oder Referencen als Attribute hat.Im Internet konnte ich dazu auf die schnelle aber nichts finden und wo ich's ausprobiert hab hat er's auch kopiert wie er's sollte.
Hat mein Prof. nun unrecht oder war das gaaanz früher mal so?
mfg Dweb
-
Der Standard-Copy-Ctor erstellt nur eine flache Kopie.
Hast du zum Beispiel Pointer als Attribut, werden nur die Pointer, nicht die Objekte dahinter kopiert. Beide Kopien zeigen danach also auf das selbe Objekt, was eher selten gewünscht ist
-
joa das weiß ich schon^^.
Meinte aber wenn du als Attribut eine Konstante hast, und dann ein Objekt kopierst, dass die Konstante (laut meinem Prof.) nicht mitkopiert wird.
-
Der implizit definierte Copy-ctor kopiert alle Basisklassen und Member einzeln der Reihenfolge nach. Falls ein Member nicht kopiert werden kann, wird auch kein Copyctor generiert und es ist dann ein Fehler, ein solches Objekt kopieren zu wollen. Das kann aber nur passieren, wenn das jeweilige Element wegen fehlender Zugriffsrechte (oder ungeschickter Überladung) nicht kopiert werden kann oder seinerseits einen implizit deklarierten Copyctor hat, der nicht generiert werden kann.
Referenzen und konstante Member folgen hier keinen besonderen Regeln.
Was explizit definiert werden muss, ist ggf. ein Defaultkonstruktor. Da Refernzen und konstante nichtstatische Member explizit initialisiert werden müssen, wird bei Anwesenheit solcher Member kein Defaultkonstruktor implizit deklariert. Zudem kann der implizit deklarierte Zuweisungsoperator nicht definiert werden.Allerdings sind Referenzen und konstante nichtstatische Member ohnehin in fast allen Klassen deplaziert.
-
camper schrieb:
Referenzen und konstante Member folgen hier keinen besonderen Regeln.
ky, dann hat mein Prof. unrecht gehabt.
-
Um's nochmal auf'n punkt zu bringen: Eine Referenz als nichtstatisches Element verhindert einen Compiler-generierten Zuweisungsoperator, nicht aber einen Kopierkonstruktor. Das neue Referenz-Element referenziert dann dasselbe Objekt wie die Referenz aus dem Quellobjekt.
Gruß,
SP
-
camper schrieb:
Allerdings sind Referenzen und konstante nichtstatische Member ohnehin in fast allen Klassen deplaziert.
huch???
referenzen verwende ich kaum (als member), aber nicht-statische konstanten eigentlich dauernd.
sehr viele klassen haben "init-only" member. die mache ich dann gern konstant. um fehler zu vermeiden, und es dokumentiert auch gut was veränderlicher state ist, und was nicht.
-
hustbaer schrieb:
sehr viele klassen haben "init-only" member. die mache ich dann gern konstant. um fehler zu vermeiden, und es dokumentiert auch gut was veränderlicher state ist, und was nicht.
Viele Klassen, selbst wenn sie Kopieren nicht unterstützen, könnten problemlos movable oder swapable sein - und das dürfte auch für viele die init-Fälle zutreffen. In solchen Fällen ist die Verwendung von const-Membern unnötig einschränkend.
Teilbaren (in veräbnderbaren/nicht-veränderbaren) State zu haben, scheint mir schwer mit dem one-class-one-responsibility-Prinzip vereinbar zu sein. Jedenfalls sind mir bisher kaum überzeugende Beispiele eingefallen, die den Sinn von konstanten Membern darstellen würden.
Zwei Fallgruppen sind noch die wahrscheinlichsten Kandidaten:
- Singletons: hier entfällt das movable/swapable-Argument
- Proxies: da diese Referenzen imitieren, überrascht hier nicht, dass Referenzen als Member verwendbar sind, da Kopier- und Zuweisungssemantik auseinanderfallen. Andererseits könnte man auch das Proxieobjekt selbst während seiner gesamten Lebenszeit als konstant (eigentlich: stateless) ansehen, die Konstanz der Member ist dann wiederum nur Folge der Konstanz des gesamten Objektes.Meine Aussage war auch primär eher an weniger Erfahrene gerichtet: im Forum sieht man öfter Code, in dem Member nur deshalb const sind, weil der Schreiber nicht die Absicht hat, das Klassenobjekt jemals zu verändern, aber nicht weil diese Konstanz im einzelnen Member selbst angelegt ist. Das ist dann ein typischer Fall der Kategorie: "wenn es konnst sein kann, mach es const", was ich nicht für zielführend halte.
