B *pB= new B();
C *pC= new C();

A *p= pB;
A *p= pC;

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

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.

...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.

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

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.

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??

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

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

...

((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.

...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.