Warum keine Vererbung von operator=
-
struct Bar; struct Foo { Bar& operator=(const Bar&); // gleiche Signatur wie Copy-Zuweisungsoperator in Bar Foo& operator=(const Foo&); }; struct Bar { using Foo::operator=; };Bar hat jetzt die Zuweisungsoperatoren
Bar& Bar::operator=(const Bar&) (implizit deklariert und verdeckt immer noch den operator gleicher Signatur in Foo)
Foo& Bar::operator=(const Foo&) (aus Foo, eigentlich verdeckt, durch using sichtbar gemacht)Die Verdeckung des Operators gleicher Signatur aus der Basisklasse ist hier allerdings eine Spezialregel der using-Deklaration - die allgemeine Regel würde Mehrdeutigkeit implizieren (dann hätte die Klasse aber gar keinen Kopierzuweisungsoperator - das darf nicht sein) oder die Verhinderung der impliziten Deklaration.
Simon2s Standpunkt ist durchaus haltbar - ich bestreite nur, das meine Argumentation widersprüchlich ist.
-
oehm Moment. Wer erbt hier von wem? In diesem beispiel gibts garkeine Vererbung und daher wird auch kein geerbter op= verdeckt. So wie es hier steht hast du zwei unabhaengige Klassen die beide die zwei gleichen Zuweisungsopis haben - wobei ich bezweifle dass das das so kompiliert, zumindest nicht, wenn du irgendwelche Member hast die du in den op= bearbeitest.
-
camper schrieb:
...ich bestreite nur, das meine Argumentation widersprüchlich ist.
Ach sooooo - das war wohl nur ein Mißverständnis: Ich meinte nicht, dass DEINE Argumentation widersprüchlich sei, sondern hustbaers Aussage "geerbte Funktionen kann man nicht überladen" (die er natürlich auch nicht in der Allgemeinheit meinte) relativieren wollen !
Dafür habe ich Deine Aussage benutzt.Sorry, dass ich das in dem Zusammenhang nicht klar genug rausgestellt habe.
Gruß,
Simon2.
-
pumuckl schrieb:
oehm Moment. Wer erbt hier von wem? ...
Naja, das ist doch wohl eher ein schnell identifizierter Typo. Gemeint ist bestimmt:
struct Bar; struct Foo { // ... }; struct Bar : Foo { // ..Würde ich jetzt jedenfalls aus dem Zusammenhang (und der Namensgebung) schließen.
pumuckl schrieb:
...
struct A { A& operator= (const A&); }; struct B : A { A& operator= (const A&); //Aeusserst ungewoehnlich, aber machbar };...
Trotzdem bekommt (IIRC) B hier noch einen operator=(const B&) verpasst, dessen Signatur "nicht passt".
Aber nun hängt Euch doch nicht so an meiner Randbemerkung auf !!
Ich habe NIEEEMALS behauptet, dass die Verdeckung unwichtig, sondern nur, dass es selbst dann nicht funktionieren würde, wenn die C++-Designer das mit der Verdeckung anders geregelt hätten.
Den fachlichen Grund dafür hat Jaxom bereits in seinem ersten Posting genannt ("...es würden nur Basisklassenanteile kopiert, es würden Redundanzen entstehen usw...."); worin sich das technisch/semantisch ausdrückt, wollte ich mit dem Hinweis auf die Signatur unterstreichen - mehr nicht.Gruß,
Simon2.
-
Simon2 schrieb:
pumuckl schrieb:
oehm Moment. Wer erbt hier von wem? ...
Naja, das ist doch wohl eher ein schnell identifizierter Typo. Gemeint ist bestimmt:
struct Bar; struct Foo { // ... }; struct Bar : Foo { // ..Jo, das wars. danke.
-
camper schrieb:
...Jo, das wars. danke.
Gern geschehen !
-
@Simon2:
Ich verstehe immer noch nicht wie du geerbte Funktionen überladen willst.
Überladen heisst für mich dass beim Aufruf auch "overload resolution" gemacht wird, und wenn ich durch den vermeintlichen "Overload" alle gleichnamigen Funktionen der Basisklasse verdecke, dann passiert eben keine "overload resolution" mehr wenn ich unqualifiziert aufrufe. Und wenn ich mit der Basisklasse qualifiziere ... dann wird der neue "Overload" in der abgeleiteten Klasse auch nicht verwendet.Also. Wie überlade ich geerbte Funktionen?
-
hustbaer schrieb:
Also. Wie überlade ich geerbte Funktionen?
Indem ich sie per using in den Scope der abgeleiteten Klasse ziehe und dann überlade
-
-
CStoll schrieb:
hustbaer schrieb:
Also. Wie überlade ich geerbte Funktionen?
Indem ich sie per using in den Scope der abgeleiteten Klasse ziehe und dann überlade
using gilt nicht, das ist geschummelt
