ich will gerade in einem Projekt die rtti verwenden, und verstehe einfach nicht, warum sie so langsam ist. Hier ein simpler Test typeid == typeid vs int == int:

#include <ctime>
#include <iostream>
#include <typeinfo>

const unsigned int loops = 100000000;

int main()
{
    volatile unsigned int a = 1;
	volatile unsigned int b = 2;

	unsigned int dummy = 0;

	unsigned int t = std::clock();
	for( unsigned int i = 0 ; i < loops ; ++i )
	{
		if( a == b )
			++dummy;
	}
	std::cout<< std::clock() - t <<std::endl;

	t = std::clock();
	for( unsigned int i = 0 ; i < loops ; ++i )
	{
		if( typeid( int ) == typeid( double ) )
			++dummy;
	}
	std::cout<< std::clock() - t <<std::endl;

	std::cin.get();
}

Auf meinem Rechner ist die Ausgabe
- mit VC++2010 release: 209 ; 1932
- mit mingw und gcc -03: 190 ; 1979

Warum ist das so? Müsste ich rtti selbst bauen, würde ich typeid einfach als einzigartigen uint Wert umsetzen.
Warum schneidet typeid also auf den beiden compilern (ich nehme mal an, dass das bei anderen nicht viel anders sein wird) so viel schlechter ab? Und warum optimiert keiner der beiden compiler die zweite Schleife einfach weg?

EDIT: Ich glaube ich habe grade herausgefunden, warum es so lahm ist: Anscheinend Vergleichen die beiden compiler die Namen der beiden types miteinander, d.h. strcmp. Das erscheint mir doch ziemlich seltsam. Warum sollte man sowas machen? Nur damit typeid auch über dll Grenzen funktioniert? Dafür muss es doch wohl bessere Lösungen geben als sowas unsicheres - was ist wenn verschiedene Typen gleich heißen? Bin ernsthaft etwas verwirrt

Überhaupt führt die Existenz von Laufzeitlinkern (d.h. dlopen/LoadLibrary etc.) hier unter Umständen zu gewissen Schwierigkeiten. Vermutlich benutzt die GNU-Implementation folgende Variante des operator==:

bool operator==(const type_info& __arg) const
    {
      return ((__name == __arg.__name)
              || (__name[0] != '*' &&
                  __builtin_strcmp (__name, __arg.__name) == 0));
    }

Übersetz den Code mal mit

if( typeid( int ) == typeid( int ) )

. Wahrscheinlich fällt der Unterschied dann wesentlich kleiner aus.

Ich vermute aber, dass in derart einfachem Code ohne dynamisch dazugeladene Komponenten die Bedingung __name[0] != '*' nie hält und im Ungleichheitsfall unabhängig vom Namen der betreffenden Typen immer nur die Zeiger verglichen und über das erste Zeichen des Namens festgestellt wird, dass ein String-Vergleich einen auch nicht weiterbrächte. Ich hätte jetzt nicht zwingend vorhergesagt, dass das in der Performance einen Faktor von 2 ausmacht, aber etwas in der Größenordnung scheint realistisch.

Sonst könnte man z.B. inetwa sowas machen:

struct _TypeInfoData
{
    long long _HashCode;   // Hashcode von _TypeName, nach irgendeinem genau definierten, schlauen Algorithmus
    char const* _TypeName; // Zero-padded auf z.B. Vielfache von 8 Byte
};

class type_info
{
public:
    // ...

    bool operator == (type_info const& other) const
    {
        if (other._Data == _Data)
            return true;  // Adresse gleich -> muss gleicher Typ sein
        else if (other._Data->_HashCode != _Data->HashCode)
            return false; // Hashcode unterschiedlich -> muss anderer Typ sein
        else
                          // Doof, wir müssen vergleichen
            return fast_8b_padded_strcmp(other._Data->_TypeName, _Data->_TypeName) == 0;
    }

    // Analog dazu operator != () und before()

private:
    type_info(_TypeInfoData const* data) : _Data(data) {}

    type_info(type_info const&);
    type_info& operator =(type_info const&);

    _TypeInfoData const* _Data;
};

Ein wirklicher String-Vergleich wäre damit nur mehr in einigen wenigen Fällen nötig (=wenn die _TypeInfoData Instanzen in verschiedenen DLLs/SOs stehen, der Typ aber der selbe ist, oder wenn man sehr sehr viel Pech mit dem Hashcode hat).

Macht aber (fast?) keiner, weil keiner mit "seiner" ABI brechen will. Über ähnliche Mechanismen liesse sich vermutlich auch dynamic_cast etwas beschleunigen. Macht aber auch (fast?) keiner.

-----

BTW: nachdem ich gerade es sebst ergoogelt habe, und nicht uninteressant finde: die "Vendor-Neutral C++ ABI" die GCC verwendet ist die, die ursprünglich für Itanium definiert wurde, und ist (laut Wikipedia) hier dokumentiert:

http://sourcery.mentor.com/public/cxx-abi/abi.html
http://sourcery.mentor.com/public/cxx-abi/abi-eh.html

Hast du Optimierung angeschaltet?

ja -O3 bzw halt die normalen release Einstellungen von msvc++.

Ich habe nicht vor eine dynamic_cast oder typeid Orgie anzurichten, keine Sorge.

Es ist aber sehr wahrscheinlich, dass du gerade dabei bist, dir basierend auf typeid einfach nur eine Art dynamic_cast zu basteln, auch wenns auf den ersten Blick vielleicht nicht direkt danach aussieht...

GorbGorb schrieb:

Ich habe nicht vor eine dynamic_cast oder typeid Orgie anzurichten, keine Sorge.

Es ist aber sehr wahrscheinlich, dass du gerade dabei bist, dir basierend auf typeid einfach nur eine Art dynamic_cast zu basteln, auch wenns auf den ersten Blick vielleicht nicht direkt danach aussieht...

Wobei dynamic_cast auch nicht unbedingt schneller sein wird als typeid()...

dot schrieb:

GorbGorb schrieb:

Ich habe nicht vor eine dynamic_cast oder typeid Orgie anzurichten, keine Sorge.

Es ist aber sehr wahrscheinlich, dass du gerade dabei bist, dir basierend auf typeid einfach nur eine Art dynamic_cast zu basteln, auch wenns auf den ersten Blick vielleicht nicht direkt danach aussieht...

Wobei dynamic_cast auch nicht unbedingt schneller sein wird als typeid()...

Normalerweise dürfte sogar eher das Gegenteil der Fall sein, da dynamic_cast die komplette Hierarchie beachten muss...
Aber darum gehts mir auch nicht. Mir geht's darum, dass typeid und dynamic_cast meist Sympton eines Designproblems sind. Es wäre also sinnvoll, zumindest mal zu reflektieren, was man da eigentlich gerade zu tun gedenkt, anstatt mit dem Kopf durch die Wand zu laufen.

entity -> entity_system -> (über virtuelle Funktion) -> meta_entity_system<...> (kennt den Typ der folgenden container) -> container< ComponentType* >

entity_system weiß noch nicht, für welche Typen es container gibt. Dadurch muss ich nicht alles, das entity_system verwendet, neu compilen, wenn ich einen neuen Komponententyp einbaue.
In meta_entity_system muss ich dann aber wissen, welche Komponententypen in der entity stecken, also brauche ich rtti.

Edit: Ok, es könnte eine neue Komponente was mit einer neuen Schnittstellen anfangen. RTTI wäre da theoretisch eine Lösung, wird praktisch aber schon rein auf technischer Ebene nicht unproblematisch sein, da die Typen, mit denen du es da zu tun hast, wohl aus verschiedenen dlls stammen müssen. Fakt ist, dass Code nur Schnittstellen verwenden kann, die zur Compiletime bekannt sind. Ich denk, dass es da eine bessere Lösung geben muss. Ich frag mich eben grad, was genau der Sinn davon ist, die Komponenten zentral zu verwalten, wenn es doch offenbar an zentraler Stelle nicht genug Information dafür geben kann.

Geht es dir um eine Art Framework zur Verwaltung von Metadaten, d.h. Abhängigkeitsauflösung zur Laufzeit? Das wäre vorstellbar, aber dafür solltest du keine Typidentifikation zur Laufzeit brauchen. Das ginge wahrscheinlich sogar ohne virtuelle Methoden.

So richtig klar ist mir nicht, was du unter "componend based design" verstehst; wenn Komponenten bei dir bloß Daten sind, ist es jedenfalls nicht das, was ich meinte. Kannst du vielleicht etwas genauer beschreiben, was du eigentlich erreichen willst?

Im Grunde geht es darum, dass man statt mit einer Klassenhierarchie mit aus mehreren Komponenten zusammengesetzten Objekten (entities) arbeitet. Eine entity ist nur eine einzigartie id, der mehrere Komponenten zugeordnet sind.
Die Komponenten werden dann seperat voneinder gespeichert. Da Komponenten nur aus Daten bestehen werden sie von einem bestimmten subsystem bearbeitet. Wie aus dem Artikel hervorgeht, wird das bei der Spieleprogrammierung verwendet.
Als Beispiel könnte etwa eine entity einen Baum im Spiel repräsentieren. Die entity hätte dann eine RenderComponent, eine PhysicsComponent, DestructibleComponent, ...
Es gäbe ein RenderSystem, das alle RenderComponents abarbeitet, ein PhysicsSystem für die Physik etc.
Der Vorteil ist, dass man damit verschiedene Aspekte trennen kann, statt sie in einem großen god object zu verwursteln. Abgesehen von weniger schmutzigem code kann man so leichter multi threaden und nutzt den cache durch seperate Speicherung der Komponenten besser.

Er hat ja auch Code dazu - eine Entity (der Schlüssel) ist da ein int, eine Komponente ein Array von floats (die Daten), und das System (der eigentliche Code) befasst sich dann mit der Verarbeitung. Komponenten in eine Klasse zu gießen ergibt für mein Verständnis da noch Sinn, obwohl das Interface im Wesentlichen auf eine Methode der Form "gib mir Wert X, wenn du ihn hast" hinausliefe, und um den globalen Kontext zu vermeiden, wäre eine Abstraktion für die Datenbank(verbindung) bzw. dessen, was ihre Rolle übernimmt, vermutlich sinnvoll, aber die Entity selbst, so schreibt er ja ausdrücklich, sollte die Daten nicht verwalten.

Aber wie gesagt, das alles schreibe ich unter dem Vorbehalt, dass mein Verständnis des Feldes sich auf das Lesen dieses Artikels beschränkt.

int type_count = 0;
template<class T>
int get_id(){
  static int id = type_count++;
  return id;
}

class Base{
public:
  virtual int id()const=0;
};

class Derived : public Base{
public:
  virtual int id()const{ // Kann man auch per Base<Derived> template erzeugen lassen
    return get_id<Derived>();
  }
};

template<class T>
T*my_downcast(Base*b){
  if(b.id() == get_id<T>())
    return static_cast<Derived*>(b);
  else
    return 0;
}

Eventuell kann man auch irgendwie direkt die Methodenzeiger vergleichen und sich so den virtuellen Aufruf sparen, aber den Syntax kriege ich nicht aus dem Stegreif hin.