Klasse eines Objektes bestimmen?
-
Ja, und zwar wie folgt:
#include <iostream> #include <typeinfo> using namespace std; class Test { public: Test() : myInt(5) {} virtual int GetMyInt() {return myInt;} private: int myInt; }; int main() { Test TestObj; cout << "Name der Klasse: "; cout << typeid(TestObj).name() << endl; //Gibt auf meinem Compiler "4Test" aus return 0; }Ansonsten kannst du dir auch mal die restlichen Elemente/Methoden von typeinfo angucken (also die außer name())
Felix
P.S.: IIRC musste die Klasse allerdings (mindestens) eine virtuelle Methode haben. Es geht auf meinem Compiler allerdings auch ohne...
EDIT: Hier gibts noch nen interessanten Artikel dazu. http://www.informatik.fh-luebeck.de/et/ti/Seehusen/Publications/UnixMail/4-231.pdf
-
Nun, auf meinem offenbar nicht. Jetzt aber schon, dankeschön.
Nur dass ich jetzt diese sonst recht überflüssige virtuelle Funktion mit mir rumschleppe.

-
Randfrage: Wozu musst du das überhaupt wissen? Normalerweise zeugt es von schlechtem Design, wenn du ein Objekt nach seinem Typ fragen mußt - entweder du kennst den Typ oder er sollte egal sein.
-
Ich habe ein Array voll Zeigern auf verschiedene abgeleitete Klassen einer Basisklasse, dass vorher aus einer vom User generierten Datei ausgelesen und erstellt wurde. Wenn ich da jetzt durchloope, weiß ich also nicht genau, welche abgeleitete Klasse an welcher Stelle kommt.
-
Sniffman schrieb:
....weiß ich also nicht genau, welche abgeleitete Klasse an welcher Stelle kommt.
Gut - aber wozu brauchst Du das zu wissen ?
Doch wohl nicht, um Elemente zu nutzen, die die Basisklasse nicht besitzt, oder ?
Gruß,
Simon2.
-
Um dem Benutzer anzuzeigen, welche Klasse es denn nun war.

Außerdem muss ich kleinlaut zugeben, dass ich gerade nicht ganz verstehe, was daran böse wäre, nicht gemeinsame Elemente zu nutzen. Ist das nicht der Sinn abgeleiteter Klassen?
-
Der Vorteil der abgeleiteten Klassen ist gerade, daß es dich nicht kümmern muß, welche genau du da vorliegen hast. Die Basisklasse bestimmt, was du machen kannst und jede davon abgeleitete Klasse kümmert sich um selbst darum, wie sie es machen kann.
Und wenn die Klassen so verschieden sind, daß du keine ausreichende gemeinsame Schnittstelle findest, lohnt sich die (öffentliche) Ableitung nicht mehr.
-
Wenn es nur darum geht dem Benutzer das anzuzeigen könnte man dann nicht einfach ein private Attribut std::string classname anlegen und dieses dann über eine virtuelle Methode ausgeben? Wenn nicht, was verhindert es?
-
@CStoll: Ich bin mir ziemlich sicher, dass mein Design noch optimierbar ist. Aber da das auch mein erstes Projekt in C++, inklusive Objektorientierung, ist, nehme ich das vorerst mal nicht ganz so ernst. Ich werde die Dinge aber noch weiter aufräumen und Redundanz entfernen.
@Shinja: Naja, wieso sollte ich noch ein Attribut anlegen, wenn ich auch so relativ einfach an die Infos komme? So kann ich mit einer ebenfalls virtuellen Methode für jede abgeleitete Klasse den Namen ausgeben, ohne ein zusätzliches Attribut.
-
Hi,
ich glaube, niemand hat etwas dagegen, sowas in persönlichen (Kennen-)Lernprogrammen zu sehen ... nur in "echtem Code" sollte das nur in Ausnahmefällen vorkommen ("Mit dem Rücken zur Wand ... und einem Messer an der Kehle .... einem sehr, sehr scharfen Messer.")

Außerdem kann in einem "echten Programm" kein User etwas mit einem Klassennamen anfangen...insgesamt würde ich aber Shinjas Ansatz unterstützen .. da lernst Du auch gleich ein wenig über virtual functions...

Gruß,
Simon2.
-
Den Namen der Kasse als Attribut halte ich für Überflüssig, da typeid den Zweck erfüllt. Für Logging-Aufgaben ist das typeid nicht schlecht. Ansonst ist das Ding leider ziemlich nutzlos in C++ und dient wirklich nur der Runtime.