Welcher Type? [Fuer FAQ]

Green_Ghost

Da die Frage immer wieder mal gestellt wird,
will ich sie mal im FAQ deponieren.

Run-Time-Type-Identifizierung (RTTI)
Ist das Zauberwort.
Es Erlaubt die Identifikation waerend der Laufzeit.
z.B.

#include <typeinfo>
#include <iostream>

template<typename T> ich_bin(const T &a){
	std::cout<<std::typeid(a).name()<<std::endl;
}

//Verwendung
int bla;
ich_bin(bla); //Ausgabe: int

Also mit std::typeid(obj).name() wird der Type des Objekts ausgegeben.

const char* name()

Fuer Operatoren gilt:

bool operator==(const type_info &ob);
bool operator!=(const type_info &ob);

In der Praxis etwa so:

#include <typeinfo>
#include <iostream>

template<typename T1, typename T2> ich_du(const T1 &a, const T2 &b){
	if(std::typeid(a) == std::typeid(b)){
		std::cout<<"gleich"<<std::endl;
	}else if(std::typeid(a)!= std::typeid(b)){
		std::cout<<"ungleich"<<std::endl;
	}
}

//main
int a;
double b;
ich_du(a,b); //Ausgabe: ungleich

So das ist mal ein kleines Beispiel aus der <typeinfo>
Bitte Korrigiert mich, wenn ich was falsch gesagt habe,
und ergenzungen sind immer gut

Ghost
*
[EDIT]
Bitte macht das mit der IO/Ausgabe in einer funktion nicht nach.
[/EDIT]
*

miller_m

würde sich für dein praxis beispiel nicht typetraits besser eigenen den diese
könnte man schon zur compiletime auswerten?

Bashar

Wenn Typetraits zur Compilezeit ausgewertet werden, sind sie denkbar ungeeignet, um den Laufzeittyp eines Objektes herauszufinden

Green Ghost:
Warum nicht dynamic_cast benutzen?

Green_Ghost

Mmmm, weil ich den Type herausfinden will, und nicht etwas casten.
Okey, zugegeben, ich kenne den dynamic_cast nicht gut.
Aber so wie ich das verstanden habe, hat es was mit Classen und Template
zutun. Und nicht direckt mit obj = int.

otze

Green_Ghost schrieb:

#include <typeinfo>
#include <iostream>

template<typename T> ich_bin(const T &a){
	std::cout<<std::typeid(a).name()<<std::endl;
}

//Verwendung
int bla;
ich_bin(bla); //Ausgabe: int

verlass dich nicht drauf, dass int wirklich ausgegeben wird, das garantiert der standard nämlich nicht!

Wenn Typetraits zur Compilezeit ausgewertet werden, sind sie denkbar ungeeignet, um den Laufzeittyp eines Objektes herauszufinden

in den hier gegebenen beispielen wird aber keine dynamische typisierung benutzt, deshalb ist das hier alles etwas komisch.

Bashar

Naja die Frage ist doch, wozu will man den Typ eines Objektes wissen? Um es in diesen Typ zu casten und eine speziellere Methode aufzurufen zum Beispiel. Was anderes fällt mir im Moment aber nicht wirklich ein.

Green_Ghost

@otze:
Stimmt. Ich wuerde sowas auch nie machen. Sieht ja auch ned schoen aus.
Ich hab das auch nur zu demostrations zwecken gemacht.
Aber gut das du das noch schreibst, sonst macht es vieleicht doch noch ein
anfaneger falsch.

@Bashar:
Ich hab das Manual geschrieben, weil in letzter Zeit einige so was fragten.
Ich glaube es is ne Aufgabe einer Uni/Kurs/Buch... weiss nicht.
So schreib ich mal diese variante nieder, die man natuerlich
noch ausbauen muss. Ist mir klar, soll aber auch keine Loesung sein.

Ghost

[EDIT]
Wenn es Scheisse ist, koennt ihr das schon sagen.
War ja nur ne Idee.
[EDIT]

miller_m

Bashar schrieb:

Wenn Typetraits zur Compilezeit ausgewertet werden, sind sie denkbar ungeeignet, um den Laufzeittyp eines Objektes herauszufinden

ja schon klar, aber warum muss ich überhaupt den typ zur laufzeit bestimmen
wenn ich mittels traits ein statisches konstrukt zu einem speziellen typ
schon kompilieren kann.

Bashar

Weil der Typ zur Laufzeit unterschiedlich sein kann:

Base* obj;
if (blub)
  obj = new Derived1;
else
  obj = new Derived2;

Green_Ghost

und wenn ich eine Template klasse habe, die bei int etwas anders macht
als bei char. So kann ich herausfindes was es fuer ein type ist.

HumeSikkins

Green_Ghost schrieb:

und wenn ich eine Template klasse habe, die bei int etwas anders macht
als bei char. So kann ich herausfindes was es fuer ein type ist.

Das ist kein gutes Beispiel. In so einem Fall solltest du eher Überladung bzw. Spezialisierung verwenden. Hier sind alle nötigen Informationen schließlich zur Compilezeit bekannt. Kein Grund für die RTTI-Kanone.

miller_m

Bashar schrieb:

Weil der Typ zur Laufzeit unterschiedlich sein kann:
Base* obj;
if (blub)
  obj = new Derived1;
else
  obj = new Derived2;

auch klar, ich suche nur einen "guten" grund überhaupt rtti
überhaupt einzusetzen. hat jetzt nichts direkt mit green_ghosts beitrag zu
tun, sondern nur mit dem warum.

HumeSikkins

auch klar, ich suche nur einen "guten" grund überhaupt rtti
überhaupt einzusetzen.

Spontan fällt mir da z.B. double-dispatch ein. Z.B. wie in der Implementation eines azyklischen Visitors.

audacia

HumeSikkins schrieb:

auch klar, ich suche nur einen "guten" grund überhaupt rtti
überhaupt einzusetzen.

Spontan fällt mir da z.B. double-dispatch ein. Z.B. wie in der Implementation eines azyklischen Visitors.

Und jetzt nochmal auf Deutsch.

audacia schrieb:

HumeSikkins schrieb:

auch klar, ich suche nur einen "guten" grund überhaupt rtti
überhaupt einzusetzen.

Spontan fällt mir da z.B. double-dispatch ein. Z.B. wie in der Implementation eines azyklischen Visitors.

Und jetzt nochmal auf Deutsch.

ROFLMAO :p

Ein azyklischer Visitor ist ein Designpattern -> www.google.de
DoubleDispatching ist eine Multithreading Technik, um die sicherheit eines Threads zu gewährleisten.

net 0

audacia schrieb:

HumeSikkins schrieb:

auch klar, ich suche nur einen "guten" grund überhaupt rtti
überhaupt einzusetzen.

Spontan fällt mir da z.B. double-dispatch ein. Z.B. wie in der Implementation eines azyklischen Visitors.

Und jetzt nochmal auf Deutsch.

kennst du den unterschied zwichen profi und amateur?
btw: das 'spontan' ist wichtig

Glamdrink schrieb:

DoubleDispatching ist eine Multithreading Technik, um die sicherheit eines Threads zu gewährleisten.

LOL? So ein Schwachsinn.

audacia

net schrieb:

kennst du den unterschied zwichen profi und amateur?

Ja.
Kennst du das?

otze

Glamdrink schrieb:

DoubleDispatching ist eine Multithreading Technik, um die sicherheit eines Threads zu gewährleisten.

AFAIR ist das was ganz anderes...

das double dispatching kann man ein bischen wie templates zur laufzeit sehen.(jaja, ich wusste net, wie ichs anders umschreiben sollte^^) nehmen wir mal an, wir haben folgende konstellation:

class Base{...};
class A:public Base{...};
class B:public Base{...};

void test(Base* a,Base* b);

int main(){
    Base* a=new A;
    Base* b=new B;

    test(a,b);

    delete a;
    delete b;
}
}

ein einfacher fall. double dispatching löst das problem, wenn die Funktion test,je nachdem welche typen sich hinter a und b verstecken, sich anders verhalten soll(also doch en bissl wie templates^^)

ein einfaches beispiel wäre zb ein test ob zwei verschiedene formen sich überlappen, bei 2 kreisen muss das anders funktionieren als bei 2 quadraten, und bei einem kreis und einem quadrat ist das auch wieder anders.

/wie gesagt, alles AFAIR^^)