3. Wie nennt man Event Empfänger?

Wie nennt man Event Empfänger?

  • ?

    Hallo,

    Ich habe eine Klasse, die sich bei einer anderen registriert und bei der eine Methode aufgerufen wird, wenn ein Event ausgelöst wurde.
    In PseudoCode quasi so:

    class Foo { // Ist an Events interessiert
public
   virtual void handleEvent(Bar*  b) = 0;

};

Foo* f = new Foo;
bar->register???(f); // Wenns ein Event gibt, wird f->handleEvent() aufgerufen

    Wie nennt man eine Klasse wie Foo? Also ein Ding, das an Events interessiert ist.

    0
  • 3

    Handler

    0
  • T

    Oder auch Observer/Listener

    0

  • Sink
    Receiver
    Client
    Subscriber
    ...

    0
  • 3

    Der nächste sagt dann bitte 8 Begriffe, immer in Zweierpotenzen weiter 🤡

    0
  • E

    In C++ sind signals aber eleganter, um Observer/Listener zu implementieren. Man muss nicht wie in Java zig Interfaces definieren, um zu erreichen, was man möchte. Außerdem kann man sich dann die Polymorphie sparen und somit die Indirektion über Zeiger. Dann kann man auch den automatischen Speicher wieder nutzen (ohne new).

    0

  • Wie willst du dir mit "signals" eine Indirektion sparen?
    Und was hat das alles jetzt mit automatischem Speicher zu tun?
    ... 😕

    0
  • E

    Hm, hatte nen gedanklichen Fehler. Man muss ja ohnehin Zeiger/Referenzen übergeben, also zählt das nicht. Aber man spart sich bei den signals zumindest den polymorphen Aufruf, den man beim Observer-Pattern mit Klassenimplementierung hat.

    0
  • N

    Eisflamme schrieb:

    Aber man spart sich bei den signals zumindest den polymorphen Aufruf, den man beim Observer-Pattern mit Klassenimplementierung hat.

    Was denkst du, wie Signals intern den Dispatch durchführen?

    0
  • S

    Nexus schrieb:

    Eisflamme schrieb:

    Aber man spart sich bei den signals zumindest den polymorphen Aufruf, den man beim Observer-Pattern mit Klassenimplementierung hat.

    Was denkst du, wie Signals intern den Dispatch durchführen?

    Du sparst dir bei signalen eine Zeiger indirektion (naemlich den der vtable).

    0
  • N

    Shade Of Mine schrieb:

    Du sparst dir bei signalen eine Zeiger indirektion (naemlich den der vtable).

    Meinst du mit Signale jetzt Funktionszeiger? Ich habe eher an std::function gedacht, weil Funktionszeiger viel weniger mächtiger sind als ein polymorphes Listener-Objekt.

    Und ich gehe stark davon aus, dass std::function intern Type Erasure über virtuelle Funktionen verwendet, damit sie mit allen möglichen Funktionsobjekten, Funktionszeigern und Memberfunktionszeigern zurecht kommt. Dann hätten wir wieder die Indirektion über die VTable. Oder übersehe ich etwas?

    0
  • S

    Nexus schrieb:

    Und ich gehe stark davon aus, dass std::function intern Type Erasure über virtuelle Funktionen verwendet, damit sie mit allen möglichen Funktionsobjekten, Funktionszeigern und Memberfunktionszeigern zurecht kommt. Dann hätten wir wieder die Indirektion über die VTable. Oder übersehe ich etwas?

    Vermutlich tut es das.

    Aber prinzipiell sind signale ohne Probleme ohne vtable implentierbar. Da man eine vtable nur brauchen wuerde wenn man type erasure macht, was nicht zwinigend notwendig ist.

    0
  • T

    Shade Of Mine schrieb:

    Nexus schrieb:

    Und ich gehe stark davon aus, dass std::function intern Type Erasure über virtuelle Funktionen verwendet, damit sie mit allen möglichen Funktionsobjekten, Funktionszeigern und Memberfunktionszeigern zurecht kommt. Dann hätten wir wieder die Indirektion über die VTable. Oder übersehe ich etwas?

    Vermutlich tut es das.

    Aber prinzipiell sind signale ohne Probleme ohne vtable implentierbar. Da man eine vtable nur brauchen wuerde wenn man type erasure macht, was nicht zwinigend notwendig ist.

    Hier gibt es eine Implementierung von Delegates ohne vtable. Aber ohne Indirektion kommt man dabei auch nicht aus.

    0
  • K

    "Polymorphe Funktionen" kann man vom Ansatz her so implementieren.

    Aber ich meine auch, von zwei Optimierungen gelesen zu haben, die man da noch einbauen könnte:
    - Small Function Optimization (umgeht dynamische Allozierung bei kleinen, leicht kopierbaren Funktionsobjekten)
    - Verwendung von drei Funktionszeigern (aufrufen,clonen,zerstören) statt virtueller Funktionen einer Basisklasse (reduziert angeblich bei dem ein oder anderen Compiler die Größe des Executables).

    0
  • E

    Okay, so weit hatte ich nicht gedacht. Dann fällt wirklich nur höchstens eine Indirektion weg.

    Dann ist aber immer noch ein Argument für signals, dass man Klassen für etwas spart, was eigentlich nur eine Verknüpfung anderer Klassen umsetzt und keinen eigenen Zweck hat und daher nicht zwangsläufig die Existenzgrundlage einer Klasse hat.

    0
Anmelden zum Antworten