Veerbung, Implementationsprinzip

Hoi Leute,

Folgendes:
Ich bin mir nicht ganz im Klaren was passiert, wenn

1. die Grundklasse, von der public abgeleitet werden soll, mindestens eine rein virtuelle Methode besitzt, jedoch keine Konstruktoren/Destruktoren.

- Schätzung: Abgeleitete Klassen rufen implizit den Standard ctor und dtor auf.

2. wäre es programmiertechnisch sauberer, wenigstens einen virtuellen dtor zu implementieren?

3. Wenn mindestens eine rein virtuelle Methode exisitiert, sollte dann ÜBERHAUPT ein ctor verwendet werden? Und wenn ja, wird dieser dann überhaupt benutzt? Denke schon, siehe 1.

4. Wie verhält sich das Ganze, wenn ich eine implementierte Methode zusätzlich zu einer rein virtuellen Methode habe, und eine Klasse ableite. Diese Methode sei privat und starr. Soweit ich weiss, werden nicht-virtuelle Methoden statisch gelinkt. Das heißt, dass jedes abgeleitete Objekt im Endeffekt immer auf die Methode im virtuellen Objekt zugreift, was kein Problem ist, da diese sich nicht ändert.
Da allerdings auch private Elemente ausgegeben werden, welche sind dies dann?

Zusammenfassend:
Wie gehe ich am besten vor, wenn ich virtuelle, rein virtuelle Methode mit implementierten in einer Basisklasse deklariere/definiere, und von dieser ableiten will? Sollte man das vermeiden, und wenn ja, wie sehen die Alternativen aus?

Lg,
Schwurbel

volkard

Schwurbel schrieb:

1. die Grundklasse, von der public abgeleitet werden soll, mindestens eine rein virtuelle Methode besitzt, jedoch keine Konstruktoren/Destruktoren.
- Schätzung: Abgeleitete Klassen rufen implizit den Standard ctor und dtor auf.

jo.

2. wäre es programmiertechnisch sauberer, wenigstens einen virtuellen dtor zu implementieren?

jo. denn irgend ein nasenbär wird sicherlich einen vector<Base*> anlegen und lauter zeiger auf oekte abgeleitet klassen reinstopfen und am ende macht er nur delete auf jeden zeiger. und eine andere nase erbt von der basisklasse und fügt einen sting als attribut ein.

3. Wenn mindestens eine rein virtuelle Methode exisitiert, sollte dann ÜBERHAUPT ein ctor verwendet werden? Und wenn ja, wird dieser dann überhaupt benutzt? Denke schon, siehe 1.

ja.

class Vogel{
   string name;
public:
   //KEIN default-ctor
   Vogel(string name);//garantiert, daß jeder vogel einen gültigen namen hat!
   ...
   virtual void flieg()=0;
};

und die erben müssen den vogel-ctor in ihrer initialisiererliste aufrufen.

4. Wie verhält sich das Ganze, wenn ich eine implementierte Methode zusätzlich zu einer rein virtuellen Methode habe, und eine Klasse ableite. Diese Methode sei privat und starr. Soweit ich weiss, werden nicht-virtuelle Methoden statisch gelinkt. Das heißt, dass jedes abgeleitete Objekt im Endeffekt immer auf die Methode im virtuellen Objekt zugreift, was kein Problem ist, da diese sich nicht ändert.
Da allerdings auch private Elemente ausgegeben werden, welche sind dies dann?

hä?

Wie gehe ich am besten vor, wenn ich virtuelle, rein virtuelle Methode mit implementierten in einer Basisklasse deklariere/definiere, und von dieser ableiten will? Sollte man das vermeiden, und wenn ja, wie sehen die Alternativen aus?

nee, nix vermeiden.

Erstmal vielen Dank, Volkard!

Das "Hä?" bezieht sich wohl auf folgendes:

[...]
class Object
{
public:
	Object(int);
	virtual ~Object(){};
	virtual void vonAussen(int)=0;

private:
	string toString();
	int m_iID;
};

Object::Object(int iID)
: m_iID(iID)
{}

string Object::toString()
{
	string sTemp(m_iID); // bin mir nicht sicher, KA von strings
	return sTemp;
}
[...]
---------------------------------------------

[...]
class Derived
{
public:
	Derived(int);
	~Derived(){};

	void vonAussen(int);
};

Derived::Derived(int iID)
: Object(iID)
{}

void Derived::vonAussen(int iSelektor)
{
	if (iSelektor)
		cout << this->toString();
}
[...]

unter main:
Derived DTest(25);
DTest.vonAussen(1);

DTest.vonAussen(1); sollte nun 25 liefern.
Allerdings ist toString ja nicht virtuell deklariert. Also wird immer Object::toString() aufgerufen.

Oder wie jetzt?

LG,
Schwurbel

virtuell Realisticer

Hallo,

Derived kann auf 'toString' gar nicht zugreifen, da es private ist.

mfg
v R

Ups, stimmt, mein Fehler. Bin auf der Arbeit, kann mich da nicht konzentrieren. Es sollte natürlich protected sein um zu funktionieren.

Aber die Frage bleibt.

phlox81

Wenns nicht virtuell ist, wird imho immer die aktuelle Methode der Klasse
bzw. des Typen der Variablen aufgerufen.