Laufzeitpolymorphie, performanteste Realisierung gesucht

nurf

Hallo Kollegen,

gegeben sei folgende Objekt-Struktur auf die ich keinen Einfluss habe.
Ich habe sie für dieses Forum etwas vereinfacht:

// Definition der Eigenschaften
class BaseProperty { ... };

class AProperty : public BaseProperty { ... };
class BProperty : public BaseProperty { ... };

// Definition eines Objekt-Typen
class ObjDescription
{
private:
  std::vector<BaseProperty*> mProperties;
public:
  bool hasElch() const
  {
    boost_foreach(mProperties, oneProperty)
    {
       // Casus Knackus
       if ( dynamic_cast<ElchProperty*> (oneProperty) )
         return true;
    }
    return false;
  }
  // analog templatisiert
  bool hasGeneric<class PropertyClass> () const { ... }; 
}

Leider ist dieses System voller Dynamic_Casts, siehe "Casus Knackus".

Momentan spiele ich mit dem Gedanken die dynamic_casts durch etwas "schnelleres" und evtl. Schöneres zu ersetzen, z.B. typeid.

Was habt ihr so für Vorschläge und Ideen ?
Erlaubt sind C++, STL und Boost.

Gruß
nurF

Eisflamme

Nur, dass ich das richtig versteh: ObjDescription darfst Du ändern, die anderen Klassen aber nicht? Sonst wäre theoretisch auch ein polymorpher Ansatz möglich.

Nexus

Du könntest Zeiger auf konstante std::type_info s in einem separaten Container C speichern, welche die Typinformationen der Elemente aus mProperties enthalten. Mit std::type_info::before() könntest du C sortieren. Die beiden Container müssen natürlich synchron gehalten werden, ansonsten ändert sich C nicht.

Ob ein Elch vorhanden ist, kannst du nun mit std::binary_search prüfen. Das zu suchende Argument erhältst du durch typeid(ElchProperty) .

nurf

Eisflamme schrieb:

Nur, dass ich das richtig versteh: ObjDescription darfst Du ändern, die anderen Klassen aber nicht? Sonst wäre theoretisch auch ein polymorpher Ansatz möglich.

Ich darf die Implementierung der "hasElch" Funktion verändern, darüber hinaus gehende Änderungen muss man genauer analysieren.
Momentan gibt es über 50 Property-Klassen. Beschreibe doch mal deinen polymorphen Ansatz.

Nexus schrieb:

Du könntest Zeiger auf konstante std::type_info s in einem separaten Container C speichern, welche die Typinformationen der Elemente aus mProperties enthalten. Mit std::type_info::before() könntest du C sortieren. Die beiden Container müssen natürlich synchron gehalten werden, ansonsten ändert sich C nicht.

Ob ein Elch vorhanden ist, kannst du nun mit std::binary_search prüfen. Das zu suchende Argument erhältst du durch typeid(ElchProperty) .

Sowas in der Art schwebt mir momentan auch vor.

Wenn du nur hasElch ändern darfst, hast du wenig möglichkeiten.

Ansonsten ein hasElch Flag, das schon beim hinzufügen zu mProperties gesetzt wird, wenn einfügen viel seltener passiert als hasElch