Subklasse- Typ aus Basisklassen Objekt (Zeiger) rausfinden

bluecode

Du kannst den pointer dynamic_cast'en (in den entsprechenden Subpointertyp). Falls 0 rauskommt ist es nicht der Untertyp, andernfalls schon und du kriegst einen Pointer auf die abgelittene Klasse.
Aber eigentlich widerspricht das dem Konzept von Vererbung.

CStoll

Am besten solltest du dein Design so entwickeln, daß du gar nicht selber nach dem Typ fragen mußt - alle wichtigen Methoden werden von A abstrakt deklariert und von den Kindklassen mit dem richtigen Verhalten ausgefüllt.

Simon2

BorisDieKlinge schrieb:

...wie bekomm ich nun rauser welcher sub typ p ist???

Warum solltest Du das ?
Wenn es wirklich sein sollte (und ich denke, dass das höchstens zu Testzwecken sinnvoll ist), kannst Du A eine virtuelle Funktion geben, die das Gewünschte liefert:

class A {
public:
    ...    
    virtual std::string whoami() { return "A"; }
};

class B {
public:
    ...    
    virtual std::string whoami() { return "B"; }
};

class C {
public:
    ...    
    virtual std::string whoami() { return "C"; }
};

int main(void) {
    A* pC = new C;
    A* pB = new B;

    std::cout << pC->whoami() << "\n"; // -> liefert "C"
    std::cout << pB->whoami() << "\n"; // -> liefert "B"
...
}

Aber wie gesagt: Ich rate dringend davon ab, das ernstlich in seinem Programm zu verwenden !!

Gruß,

Simon2.

LowFly

also wenn du Objecte hast zum vergleichen wie zum beispiel eine Liste, Combobox, Edit usw. dann sollte volgendes funzen
if(((CListCtrl*)GetDlgItem(IDC_LIST)) == p)

wenn du nen dialog hast kann ich jetzt nur raten (werd das nach her mal testen)
if(((CDialog*)GetDlgItem(IDD_DIALOG_DLG)) == p)

mfg
LowFly

Simon2

LowFly schrieb:

also wenn du Objecte hast zum vergleichen wie zum beispiel eine Liste, Combobox, Edit usw. dann sollte volgendes funzen
if(((CListCtrl*)GetDlgItem(IDC_LIST)) == p)

wenn du nen dialog hast kann ich jetzt nur raten (werd das nach her mal testen)
if(((CDialog*)GetDlgItem(IDD_DIALOG_DLG)) == p)

mfg
LowFly

Das sollte mich schwer überraschen !
Das hieße ja, dass es letztlich nur ein einziges Objekt (pro Klasse oder evtl. pro Kontext) im Speicher gäbe....
Allgemeingültig dürfte diese "Lösung" jedenfalls nicht sein.
Aber vielleicht habe ich auch zuwenig Ahnung von GetDlgItem() ....

Gruß,

Simon2.

electron

Simon2 schrieb:

Aber wie gesagt: Ich rate dringend davon ab, das ernstlich in seinem Programm zu verwenden !!

Gruß,

Simon2.

Ich habe mir jetzt keinen praktischen Nutzen überlegt, aber was spricht da dagegen?? Wieso rätst du dringend davon ab??

LowFly

@Simon2
na dann lass dich mal überraschen
anscheinend ist es dir entgangen das es möglich ist sich über mehrer
arten einen zeiger auf eine classe zu holen.

aber wie du schon richtig erwähnst

Aber vielleicht habe ich auch zuwenig Ahnung von GetDlgItem() ....

nicht nur vieleicht sondern mit absoluter sicherheit sogar.

((CListCtrl*)GetDlgItem(IDC_)

gibt dir nämlich einen zeiger auf die Classe zurück die an das Object gebunden ist.
aus diesem grund auch die Classe davor. Es ist es genau das gleiche als wenn
du dir den zeiger wie folgt holst.

CListCtrl *pListCtrl = new CListCtrl();

mfg
LowFly

akari

Electron schrieb:

Ich habe mir jetzt keinen praktischen Nutzen überlegt, aber was spricht da dagegen?? Wieso rätst du dringend davon ab??

CStoll schrieb:

Am besten solltest du dein Design so entwickeln, daß du gar nicht selber nach dem Typ fragen mußt - alle wichtigen Methoden werden von A abstrakt deklariert und von den Kindklassen mit dem richtigen Verhalten ausgefüllt.

bis bald
akari

Simon2

LowFly schrieb:

...
((CListCtrl*)GetDlgItem(IDC_)
gibt dir nämlich einen zeiger auf die Classe zurück die an das Object gebunden ist....
CListCtrl *pListCtrl = new CListCtrl();
mfg
LowFly

Das hatte ich auch so verstanden, aber üblicherweise liefert ein new eine andere Adresse als die des Objektes, das man gerade in der Hand hält.

int* p1 = new int;
    int* p2 = new int;
    if(p1 == p2) std::cout << "ich fress' 'nen Besen";

BTW: Was ein "Zeiger auf eine Klasse" ist, weiß ich nicht wirklich.
Es kann natürlich sein, dass in Deinem Code "IDC_LIST" irgendwie mit der Instanz p verknüft ist und GetDlgItem() kein neues Objekt erzeugt, sondern das assoziierte zurückgibt (von dem man angeblich nicht weiß, welchen Typs es ist).

Dann liegt aber die eigentlich "Klassenüberprüfungslogik" in dem abschließenden cast (CListCtrl*), der vermutlich sowas wie einen dynamic_cast durchführt.
Der wiederum klappt nur dann, wenn das Objekt der Klasse angehört. In dem Fall wäre das ein gangbarer Weg, aber der GetDlgItem()-Call ist dann vollkommen überflüssig ... man ist dann wieder beim "dynamic_cast-Vorschlag" von bluecode.

Gruß,

Simon2.

Simon2

electron schrieb:

...Ich habe mir jetzt keinen praktischen Nutzen überlegt, aber was spricht da dagegen?? Wieso rätst du dringend davon ab??

Weil man damit die Möglichkeiten der Vererbung aushebelt/umgeht. So ein Design wird ganz schnell unwartbartbar/unzuverlässig. Man verheddert sich dann ganz schnell in der Frage, in welcher Klasse/Funktion denn jetzt eigentlich was implementiert ist. Bei kleineren "Spielanwendungen" fällt das noch nicht so auf, aber sobald man ein paar Hundert Zeilen zusammen hat, wird das zunehmend problematischer.

Wir hatten mal einen externen MA im Projekt, der uns sowas eingebrockt hat und glaub' mir: Wir fluchen auch nach 5 Jahre noch darüber !

Letztlich gilt: Niemand kennt die Obbjekte so gut, wie der Compiler. Man sollte nicht versuchen, ihm das abzunehmen.

Gruß,

Simon2.