typeid() ... schlechter Stil?



  • Was haltet ihr denn davon:

    class Event {
      [...]
      virtual bool isInvalidatingOtherEventsOfSameType() const throw() = 0;
    }
    

    Dann gibt es ganz viele spezifische Events, die das als Basisklasse erben. Die Userklasse hat jetzt ne Methode addEvent, die folgendes macht (das auto ist ein c++0x feature, dann spart man sich die manuelle Typisierung):

    if(event->isInvalidatingOtherEventsOfSameType())
    {
      auto &addedType = typeid((*event));
      auto it = events_.begin();
      while(it != events_.end())
      {
        if(addedType == typeid((*(*it))))
        {
          it = events_.erase(it);
        }
        else
        {
          it++;
        }
      }
    }
    

    Es geht darum, dass manche Events mehrfach vorkommen dürfen und manche Events die vorherigen Events ungültig machen.

    Ein Beispiel für ein solches Event wäre die Bewegung eines Users zu einer Zielkoordinate, denn sobald er sich auf eine neue Koordinate bewegt ist das alte Event mit der alten Zielkoordinate natürlich ungültig.

    Ich persönlich bin der Meinung in meinem Usecase ist RTTI die perfekte Lösung für das Problem, oder seht ihr das anders?

    mfg, René~



  • Da keiner widerspricht, gehe ich davon aus, dass mein Usecase eine perfekte Verwendung von typeid darstellt. @OP, du siehst also, typeid ist nicht immer schlechter Stil. Wenn man allerdings nach typeid branched (switch / if..else) dann ist es wahrscheinlich anders besser lösbar.



  • NewSoftzzz schrieb:

    Da keiner widerspricht, gehe ich davon aus, dass mein Usecase eine perfekte Verwendung von typeid darstellt.

    Nein. Ich wollte mir bloß die Mühe nicht machen.
    Statt

    if(event->isInvalidatingOtherEventsOfSameType())
    {
      auto &addedType = typeid((*event));
      auto it = events_.begin();
      while(it != events_.end())
      {
        if(addedType == typeid((*(*it))))
        {
          it = events_.erase(it);
        }
        else
        {
          it++;
        }
      }
    }
    

    denke ich an

    if(event->isInvalidatingOtherEventsOfSameType())
    {
      unique_events[event->getEventClassID()]=event;
    }
    


  • volkard schrieb:

    if(event->isInvalidatingOtherEventsOfSameType())
    {
      unique_events[event->getEventClassID()]=event;
    }
    
    1. Die Events haben keine Id, da unnötiger RAM Verbrauch
    2. Die Events sind in einer std::list, da eine std::map unnötigen RAM Verbrauch bedeutet und ich außer beim hinzufügen von unique Events immer linear über alle Events iterieren muss.
    3. Welche Nachteile birgt meine typeid Lösung?

    PS: Ist eventClassId hier eine static methode die eine ID der Klasse darstellt? Wo ist da der Unterschied zu typeid? O_o

    mfg, René~



  • NewSoftzzz schrieb:

    1. Die Events haben keine Id, da unnötiger RAM Verbrauch

    Ich rede von Klassen-IDs. Auch kein RAM-Verbrauch.

    NewSoftzzz schrieb:

    1. Die Events sind in einer std::list, da eine std::map unnötigen RAM Verbrauch bedeutet und ich außer beim hinzufügen von unique Events immer linear über alle Events iterieren muss.

    Ich rede von einem Array. Daher viel weniger RAM-Verbrauch als std::list und auch viel schneller.

    NewSoftzzz schrieb:

    1. Welche Nachteile birgt meine typeid Lösung?

    Weiß nicht. Ich finde sie nicht naheliegend. Du sagst es gibt events, die ihre Verwandten automatisch töten. Ich will eher sowas wie es gibt events, die nur einmal vorkommen können.

    NewSoftzzz schrieb:

    PS: Ist eventClassId hier eine static methode die eine ID der Klasse darstellt? Wo ist da der Unterschied zu typeid? O_o

    Vielleicht kein großer. Aber wenn man schonmal so weit ist, kann man das Array auch auffächern in pro Eventklasse einen static pointer auf das unique event.
    Ich nehme an, da geht noch einiges.



  • Ach so, jetzt versteh ich das. Findest du es wirklich sinnvoll, wenn alle Algorithmen linear über die Events iterieren, die dann in mehrere Container zu verteilen? Dadurch würden die Algorithmen unnötig komplizierter.

    Desweiteren ist die Reihenfolge in der Liste äquivalent zur chronologischen Entstehung der Events, das würde durch deine Aufsplittung auch verloren gehen.

    Die Sache mit den unique Events ist eher ein Schutzmaßnahme falls die Events noch nicht vom Client abgeholt wurden und stellt keinen Regelfall dar.

    mfg, René~



  • NewSoftzzz schrieb:

    Ach so, jetzt versteh ich das. Findest du es wirklich sinnvoll, wenn alle Algorithmen linear über die Events iterieren, die dann in mehrere Container zu verteilen? Dadurch würden die Algorithmen unnötig komplizierter.

    Das eine schließt das andere nicht aus. Alle events liegen in einer (chronologischen?) Liste. Und trotzdem wird pro Eventklasse, von denen es nur eins geben kann, der unique pointer (vielleicht als list::iterator) gehalten.

    Uups, ich denke hier gleich an einen intrusiven doppelt verketten Ring denke, und normale Zeiger.



  • Mal ne Frage zwischendurch: Warum sollte man ne Liste der gefangenen Events, die noch nicht veraltet sind, speichern wollen?



  • @Volkard: Nun ja, dein Array wäre auch schon RAM Verbrauch, da zu jedem Zeitpunkt ca. 98% der User gar keine Events haben. Wenn jetzt jeder von denen so ein Array mit allen möglichen unique Events mitschleppen müsste...

    Michael E. schrieb:

    Mal ne Frage zwischendurch: Warum sollte man ne Liste der gefangenen Events, die noch nicht veraltet sind, speichern wollen?

    Das sind Ajax Events, die natürlich solange gespeichert werden bis der Client sie abholt oder sie eben ablaufen.

    mfg, René~



  • NewSoftzzz schrieb:

    @Volkard: Nun ja, dein Array wäre auch schon RAM Verbrauch, da zu jedem Zeitpunkt ca. 98% der User gar keine Events haben. Wenn jetzt jeder von denen so ein Array mit allen möglichen unique Events mitschleppen müsste...

    An wieviele unique-Typen denkst Du denn?
    Ein Server für viele Ajax-Clients also, der soo viele Clients hat, daß der Speicher ausgeht. Ist deine allocation granularity eigentlich 32 Byte? Sind das schon so viel wie ein Array mit 8 Zeigern?
    Die Schleife fühlt sich für mich einfach nicht gut an. Da bin ich verbohrt.



  • volkard schrieb:

    An wieviele unique-Typen denkst Du denn?

    Keine Ahnung, aber es werden immer mehr.

    volkard schrieb:

    Ein Server für viele Ajax-Clients also, der soo viele Clients hat, daß der Speicher ausgeht.

    Ich rechne immer mit 10 millionen. Im Moment lad ich alle in den RAM ob off- oder online. Das werd ich aber eventuell irgendwann noch ändern müssen 😉

    volkard schrieb:

    Ist deine allocation granularity eigentlich 32 Byte? Sind das schon so viel wie ein Array mit 8 Zeigern?

    Ein Zeiger hat 8 byte (64 bit).

    @Schleife: Im Regelfall liegen in der Liste 0-3 Events.

    mfg, René~



  • NewSoftzzz schrieb:

    Ich rechne immer mit 10 millionen. Im Moment lad ich alle in den RAM ob off- oder online. Das werd ich aber eventuell irgendwann noch ändern müssen 😉

    Die offliners brauchen auch eine Event-Liste?



  • volkard schrieb:

    Die offliners brauchen auch eine Event-Liste?

    Korrektur: Ja, weil Events auftreten können und abgeholt werden können beim relogin.

    mfg, René~



  • Dem habe ich dann nichts mehr hinzuzufügen.



  • typeid() ... schlechter Stil?

    Ja...


Anmelden zum Antworten