C++ Klassen Überladungs Problem

[oracle2025]

Warum kompiliert folgender Code nicht?

class A
{
	public:
		virtual void X( int ) {}
		virtual int X() { return 0; }
};

class B : public A
{
	public:
		void X( int ) {}
};


int main()
{
	B b_class;
	b_class.X();
}

ich kriege folgende Fehlermeldung, obwohl ich glaube dass das funktionieren müsste. Was habe ich übersehen?

test.cxx: In function »int main()«:
test.cxx:21: Fehler: keine passende Funktion für Aufruf von »B::X()«
test.cxx:13: Anmerkung: Kandidaten sind: virtual void B::X(int)

[pucki]

du musst mal die fehlermeldung richtig lesen und dann deinen code ;-)

X( ) != X (int)

[peschmae]

Das ist ihm (und mir) schon klar. Aber B ist ja von A abgeleitet, und A hat ein X();

Zur Frage: Ich weiss es nicht, aber vom Stil her wäre das so ne typische comp.lang.c++.moderated-Frage
Hab eben mal noch in "Design and Evolution of C++" nachgeguckt weil da so Zeugs oft noch erwähnt ist - aber dazu steht leider gar nichts.

MfG Peschmä

[locus vivendi]

Warum kompiliert folgender Code nicht?

void B::X(int) verdeckt die X in A. Du könntest entweder die X von A in B per using-Deklaration auch in B bekanntmachen, oder alle X in B reimplementieren. Siehe hier:
http://www.parashift.com/c++-faq-lit....html#faq-23.9

Ich vermute übrigens, dass du kompilierst, ohne Warnungen aktiviert zu haben. Wenn das stimmt, dann würde ich dir raten das zu ändern.

[pucki]

void B::X(int) verdeckt die X in A. Du könntest entweder die X von A in B per using-Deklaration auch in B bekanntmachen, oder alle X in B reimplementieren. Siehe hier:
http://www.parashift.com/c++-faq-lit....html#faq-23.9

Ich vermute übrigens, dass du kompilierst, ohne Warnungen aktiviert zu haben. Wenn das stimmt, dann würde ich dir raten das zu ändern.

mmmhh, also ich habe das gerade mal mit der option wall compiliert. da kommen nicht mehr meldungen, die dieses problem betreffen.

aber der link ist gut ;-) muss da nächste woche mal ein bischen tiefer reinschnuppern ..

gruesse

ps: ups, ich hatte nur flüchtig drüber gelesen .... und dachte, dass das übersehen wurde. das ist mir auch schon oft passiert. nun habe ich nebenbei noch was dazugelernt ,-)

[oracle2025]

Ich vermute übrigens, dass du kompilierst, ohne Warnungen aktiviert zu haben. Wenn das stimmt, dann würde ich dir raten das zu ändern.

Hoppla,

[oracle2025]

void B::X(int) verdeckt die X in A. Du könntest entweder die X von A in B per using-Deklaration auch in B bekanntmachen, oder alle X in B reimplementieren. Siehe hier:
http://www.parashift.com/c++-faq-lit....html#faq-23.9

Pfft, man lernt nie aus.

[panzi]

void B::X(int) verdeckt die X in A. Du könntest entweder die X von A in B per using-Deklaration auch in B bekanntmachen, oder alle X in B reimplementieren. Siehe hier:
http://www.parashift.com/c++-faq-lit....html#faq-23.9

Ich vermute übrigens, dass du kompilierst, ohne Warnungen aktiviert zu haben. Wenn das stimmt, dann würde ich dir raten das zu ändern.

Sollte es net auch gehn das eine X in B virtual zu machen?

[RHBaum]

Sollte es net auch gehn das eine X in B virtual zu machen?

Nein, weil das X in B schon Virtuell ist ....

ist eine funktion in ner basisklasse virtuell, sind alle funktionen in den abgeleiteten klassen mit gleicher Signatur (signatur != Name) auch virtuell !

Iss nur schlechter Stil das das virtual da nich dasteht ^^

Ciao ...

[panzi]

Nein, weil das X in B schon Virtuell ist ....

ist eine funktion in ner basisklasse virtuell, sind alle funktionen in den abgeleiteten klassen mit gleicher Signatur (signatur != Name) auch virtuell !

Iss nur schlechter Stil das das virtual da nich dasteht ^^

Ciao ...

aha, das wusst ich garnet.

[RHBaum]

Ja aber auch logisch, sonst koennte man ja virtualitaet wieder rueckgaengig machen ... gewollt oder ungewollt ^^
Bzw in vielen faellen waer es undefiniert, welche funktion genau aufgerufen werden wuerde, grad fuer Entwickler von Frameworks ein Horrorszenario ^^

Deswegen auch die Geschichte mit dem verdecken ....
das nicht gleich nach der Signatur, sondern erst nur nach dem Namen in der aktuellen klasse gesucht wird und versucht wird darauf zu matchen, hat natuerlich auch seine tieferen Gruende !

Stell Dir vor du hasst nen framework, da leitest von ner Klasse C ab, C ist auch dafuer vorgesehen und gut dokumentiert. Das C intern von A und B ableitet steht nirgendswo weil das implementationsdetails sind und dich nich intressieren sollt ....

Du willst aber ne Methode C::X(int) verwenden ... also :

char test = 5;
C c;
c.X(test);

sieht alles ok aus ... soweit.

Nur ein problem, dein parameter ist char, erwartet wird int, du verlaesst dich auf die impliziete Konversion. Iss ja auch zulaessig ....

Aber was wuerde passieren, wenn eine der Basisklassen A oder B eine funktion (die muss nich mal virtuell sein) X(char) haben ?
statt C::X(int) wuerde B::X(char) aufgerufen, von der du nix weisst und die sicher ned macht was du willst .
Es hilft auch nix, da B::X(char) protected zu machen, weil der eintrag wuerde trotzdem generiert werden, er wuerde trotzdem auf die funktion matchen du wuerdest nur nen Permission-Fehler bekommen, weil es protected waer.

mit char und int ist das aber noch recht uebersichtlich, nun stell dir aber mal das Szenario vor mit dem Wissen, das jeder Konstruktur mit einem Argument wie eine impliziete Konversion wirkt ....

Ciao ...