class Skill {};
class ASkill : public Skill {};
class BSkill : public Skill {};
// 100 weitere, mehrere Veerbungsebenen

class Container
{
  std::vector<Skill*> skills;

  template <typename T> bool has() 
  {
    for_each(skill, skills)
    {
       // hier liegt das Problem
       if (dynamic_cast<T*>(skill) != 0 )
       { return true; }
    }
    return false;
  }
}

main(...)
{
  Container c; // wird initialisiert etc.
  ///...
  if (c->has<ASkill>())
  {
    // whatever
  }
}

Funktioniert auch alles soweit ganz gut.
Bei realisitischem Datenbestand stellt sich allerdings heraus, dass das Programm ein Großteil der CPU-Zeit in der has-Funktion im dynamic_cast verbringt.

Nun muss das Gesamt-System irgendwie verbessert werden. Ziel des ganzen wäre es den dynamic_cast zu eliminieren und die Abfrage schneller zu machen.
Mit dem CRTP und boost::is_same komme ich nicht weiter, naja und virtual template member functions gehen eben auch nicht.
Vielleicht habt ihr eine passende Idee.

Erlaubt ist C++ (leider kein c++0x) und boost.

templates bringen dir nichts wenn du zur Laufzeit SKills austauschen können willst. Wenn Skills aber schon zur Compiletime feststehen, dann können wir was mit template Magie basteln.

Wieso kannst du nicht einfach zusätzliche Container für deine ASkill und BSkill Objekte machen?

nurf schrieb:

// 100 weitere, mehrere Veerbungsebenen

Bisschen unschön.

@nurf: Warum genau musst du denn überhaupt rausfinden ob im Container ein ASkill drin ist?

Vermutlich will er ein Item o.ä. hinzufügen, falls der Spieler eine gewisse Fähigkeit besitzt.

error C4430: Fehlender Typspezifizierer - int wird angenommen. Hinweis: "default-int" wird von C++ nicht unterstützt.

Aber gut, dass du maulst

Pi:

error C4430: Fehlender Typspezifizierer - int wird angenommen. Hinweis: "default-int" wird von C++ nicht unterstützt.

Aber gut, dass du maulst

Da hier ein C++-Forum ist, darf er maulen

Da hier ein C++-Forum ist, darf er maulen

Natürlich darf man sich über main ohne expliziten Rückgabewert beschweren. Das als "hässlichen MSVC-Schrott" abzutun, ist aber unüberlegter Unsinn, weil der VC das gar nicht schluckt.

Das bezog sich auch auf for_each du Pfeife. Lern Texte verstehen.

http://msdn.microsoft.com/en-us/library/c4x1w65f.aspx

Aber bevor du dich hier so aufspielst, solltest du erstmal deine eigenen Texte fixen...

inline unsigned int next_id()
{
    static unsigned int current_id = 1;

    return current_id++;
}
template< class Type >
class t_id
{
    static const unsigned int value;
};
template< class Type >
const unsigned int t_id< Type >::value = next_id();

t_id< X >::value ist jetzt für jede Klasse einzigartig (Achtung: funktioniert vermutlich nicht, wenn dlls im Spiel sind).
Jetzt kannst du noch die Suche von O( n ) auf O( 1 ) bringen:
Statt linearer Suche verwendest du ein Hilfsarray. lookup_vector[ t_id< Type >::value ] soll die Anzahl der Objekte eines bestimmten Typs beinhalten. Dazu muss sich jedes Objekt in dem lookup_vector registrieren (inklusive aller base classes!), wenn es in den Container aufgenommen wird und abmelden, wenn es entfernt wird:

template< class BaseType , class DerivedType >
class derived_helper
  : public BaseType
{
public:
    static void add_indices( std::vector< unsigned int >& lookup_vector )
    {
        ++lookup_vector[ t_id< DerivedType >::value ];
        BaseType::add_indices( lookup_vector );
    }
    static void remove_indices( ... )
    {
         ...
    }
};

Wenn du davor hattest

A;
B : A;

machst du jetzt halt

A;
B : derived_helper< A , B >

Du musst also die alte codebase verändern, darum kommst du wohl nicht rum (sind aber minimale Änderungen, denke ich).
Wenn du jetzt ein Objekt zu deinem Container hinzufügst, rufst du für den jeweiligen Type eben die add_indices funktion mit deinem std::vector< unsigned int > lookup_vector auf, wenn du eines entfernst die remove_indices funktion (Anm.: Falls du Objekte über einen base pointer übergibst muss die Funktion virtuell und nicht statisch sein).
Deine has< T > funktion wird dann einfach ein

template< class Type >
bool has()
{
    return lookup_vector[ t_id< Type >::value ] != 0;
}

Statt einem lookup_vector kann man denke ich auch eine andere Datenstruktur verwenden, beispielsweise ein set. Dadurch gewinnt man vielleicht etwas Speicher, verliert aber Zeit und hat wieder beim eine binary search drinnen, verliert also O( 1 ). Ist davon abhängig, wie viele verschiedene Typen tatsächlich im container gespeichert werden, was sinnvoller ist.

#define for_each(i, l) \
    for (__decltype((l).begin()) i=(l).begin(), i##_end=(l).end();
         i != i##_end; ++i)

So nutzt nurf den Wurf:

template <typename T> bool has()
  {
    for_each(skill, skills)
    {
       // hier liegt das Problem
       if (dynamic_cast<T*>(skill) != 0 )
       { return true; } // Guck mal da: returniert aus has()
    }
    return false;
  }

Schritt 1: Code des TE nochmal ansehen.
Schritt 2: Stichwort: Extension

MSVC hat keine for_each Extension, nur eine for each Extension. Das muss also irgendein Makro sein...

main(...)

Die "..." stören niemanden oder was? Vielleicht darüber nachgedacht, dass der TE nur Pseudocode gepostet hat, um zu veranschaulichen, worum es geht? Statt Hilfe kommt nur dummes Gelaber von language lawyern (naja, eigentlich nur einem) der keinem was bringt... wirklich unnötig.

class Container 
{ 
    std::vector<Skill*> skills; 

    typedef std::pair<intptr_t, intptr_t> SkillMapKey;
    typedef std::map<SkillMapKey, bool> SkillMap;  // evtl. hash_map verwenden wenns hier wirklich viele Einträge geben sollte
    SkillMap skillMap;

    SkillMapKey make_skill_map_key(Skill const* concreteSkill, type_info const& interfaceType)
    {
        return SkillMapKey(
            reinterpret_cast<intptr_t>(&typeid(*concreteSkill),
            reinterpret_cast<intptr_t>(&interfaceType));
    }

    template <typename T> bool has(Skill* concreteSkill)
    {
        SkillMapKey key = make_skill_map_key(concreteSkill, typeid(T));

        SkillMap::iterator it = skillMap.find(key);
        if (it != skillMap.end())
            return it->second;
        else
        {
            bool result = dynamic_cast<T*>(concreteSkill) != 0;
            skillMap[key] = result;
            return result;
        }
    }

    template <typename T> bool has() 
    { 
        for_each(skill, skills) 
        { 
            // hier jetzt hoffentlich schneller
            if (has<T>(skill)) 
                return true;
        } 

        return false; 
    } 
}

Wenn der Inhalt des Containers recht statisch ist könnte man natürlich noch weiter optimieren, so dass die meisten Abfragen überhaupt keine Schleife mehr brauchen.

ps: Falls "Skill" Objekte in DLLs/SOs implementiert sind, die dynamisch geladen oder und entladen werden könnte das Probleme machen. Davon abgesehen müsste es mMn. funktionieren.

Statt Hilfe kommt nur dummes Gelaber von language lawyern (naja, eigentlich nur einem) der keinem was bringt... wirklich unnötig.

Ja. Das Problem ist nur, dass man hier ohne genauere Information über die konkrete Anwendung keine hilfreiche Antwort geben kann. Denn eine gute Lösung für das Problem würde vermutlich eine grundlegende Änderung des Designs bedeuten. Und wie diese jetzt genau aussehen könnte kann man so allgemein nicht sagen...

GorbGorb schrieb:

Statt Hilfe kommt nur dummes Gelaber von language lawyern (naja, eigentlich nur einem) der keinem was bringt... wirklich unnötig.

Ja. Das Problem ist nur, dass man hier ohne genauere Information über die konkrete Anwendung keine hilfreiche Antwort geben kann. Denn eine gute Lösung für das Problem würde vermutlich eine grundlegende Änderung des Designs bedeuten. Und wie diese jetzt genau aussehen könnte kann man so allgemein nicht sagen...

Brauchst dich nicht angegriffen fühlen, ich hab dich ja gar nicht gemeint
Der TE meinte ja, es sei ein gewachsenes System, er kann vom design her wohl nicht viel ändern ohne Arbeit. Sein Problem ist diese Funktion, und ich denke da kann man ja was tun (siehe hustbaers und meine Vorschläge).

EDIT: hustbaer, wenn ich das richtig verstanden habe spart has(Skill* concreteSkill) den dynamic cast, wenn concreteSkill eines der gesuchten Objekte ist, oder? Dürften nicht vielmehr die dynamic_casts mit negativem Ergebnis das bottleneck sein?