Falls mit Registrier-Methoden:
- Wie benennt ihr die Methoden, falls es mehrere Signals gibt?
- Wie benennt ihr die Methoden, dass die Namen nicht zu lange werden?
- typedef'd ihr das signal / slot / connection?

#include <boost/signals2.hpp>

class node
{
public:
   node()
      : value_(0)
   { }

   boost::signals2::signal<void (node&)> value_changed;

   long get_value() const
   {
      return value_;
   }

   void set_value(long value)
   {
      value_ = value;
      value_changed(*this);
   }

private:
   long value_;
};

Niemals, niemals, niemals Member-Variablen public machen.Punkt! Selbst protected ist unverzeihlich.

Stirb. Membervariablen public machen, wo es Sinn macht. Das hier ist allerdings kein Fall.

#include <boost/signals2.hpp>

class node
{
public:
   node()
      : value_(0)
   { }

   long get_value() const
   {
      return value_;
   }

   void set_value(long value)
   {
      value_ = value;
      value_changed_(*this);
   }

   typedef boost::signals2::signal<void (node&)> signal_type;

   boost::signals2::connection subscribe_value_changed(signal_type::slot_type slot)
   {
      return value_changed_.connect(slot);
   }

   void unsubscribe_value_changed(boost::signals2::connection connection)
   {
      value_changed_.disconnect(connection);
   }

private:
   long value_;
   signal_type value_changed_;
};

[Edit]
Code korrigiert

Membervariablen public machen, wo es Sinn macht.

Und wo wäre das?

Brauchst du ein Unsubscribe überhaupt? Du kannst ja auf einem connection -Objekt direkt disconnect() aufrufen...

Habe ich mich auch gefragt. Es kommt mir irgendwie komisch vor wenns nur ein subscribe...(..) gibt. So unsymmetrisch.

Technisch ist das unsubscribe nicht nötig.

Habe ich mich auch gefragt. Es kommt mir irgendwie komisch vor wenns nur ein subscribe...(..) gibt. So unsymmetrisch.

Bei ähnlichen Klassen bei mir habe ich meist ein Connect() für die Registrierung sowie ein ClearConnections() , um alle Slots auf einmal zu entfernen. Aber kein Disconnect() für einen einzelnen Slot.

Falls ein unsubscribe() keine zusätzliche Funktionalität bietet, würde ich es nicht anbieten. Sonst fragt sich der Benutzer, wieso er deine Methode aufrufen soll, wenn er den Slot mit connection::disconnect() ebenfalls trennen kann...

class TriggeringTimer
{
    public:
        typedef std::tr1::function< void(TriggeringTimer&) > Listener;

    public:
        Connection    Connect(const Listener& listener);
        void          ClearConnections();
};

Wobei die Klasse halt nur ein einzelnes Signal enthält, daher kann ich allgemeine Namen wie "Listener" verwenden.

Ein Fall, in dem ich mehrere Signale hatte: Vor einiger Zeit schrieb ein paar GUI-Klassen für SFML, allerdings entwickelte ich sie nie ganz fertig. Das sah dann z.B. folgendermassen aus: Keine ClearConnections() -Funktionen, und die typedef s sind spezifischer:

class TextField
{
    public:
        Connection     ConnectTextEvent(const TextEventListener& listener);
        Connection     ConnectClick(const ClickListener& listener)
};

Ursprünglich hatte ich Bezeichner wie AddTextEventListener() , aber das war mir auf Dauer zu umständlich.

Und

Oder Server und Port eine Socketklasse.

Das hat sich mir nicht erschlossen.

Das hat sich mir nicht erschlossen.

class socket
{
public:
    const std::string server;
    const short port;
}

Markward schrieb:

Das hat sich mir nicht erschlossen.

class socket
{
public:
    const std::string server;
    const short port;
}

Also ich würde nichtmal sowas public machen.

Mal ganz davon abgesehen, dass der Name "socket" äusserst fraglich ist, für ein Ding das per Definition immer einen Port "hat" und einen Server "per Namen kennt". Das riecht eher nach einer "Connection".

Ein Socket ist eine Eindeutige Identifizierung des Endpunkts einer Verbindung. Zu eindeutig gehört nunmal auch Host und Port.

Nein.
Ein Socket ist ein Socket.
Der kann auch "unbound" sein.

Was das Thema Endpunkt angeht: was soll der String "server" da bitte bedeuten?

Soll das die lokale Adresse sein auf die der Socket gebunden ist? Wieso heisst der dann "server" und nicht "host" o.ä. Und wieso als String? Du kannst einen Socket schliesslich nicht auf eine URL binden, sondern nur auf eine Adresse (bzw. auch auf mehrere, wenn man z.B. auf 0.0.0.0 bindet).

Davon abgesehen kann man sich die Info auf welchen Port/Adresse ein Socket gebunden ist vom System holen. Die Infos permanent in Membervariablen abzuspeichern ist also redundant.

Der kann auch "unbound" sein.

Wie du den verwendest, zeigst du mir.

hustbaer schrieb:

Was das Thema Endpunkt angeht: was soll der String "server" da bitte bedeuten?

Soll das die lokale Adresse sein auf die der Socket gebunden ist? Wieso heisst der dann "server" und nicht "host" o.ä. Und wieso als String?

Ich bin hier so frei und quetsche hier nen Resolver mit nem Socket in eine Klasse. Sehr komfortabel. gethostbyname() ist ja auch nur ein Aufruf, spricht für mich nichts dagegen, das dazu zu geben.

hustbaer schrieb:

Du kannst einen Socket schliesslich nicht auf eine URL binden, sondern nur auf eine Adresse (bzw. auch auf mehrere, wenn man z.B. auf 0.0.0.0 bindet).

Ich binde ihn auf die erste IP, auf die die URL verweist.

hustbaer schrieb:

Davon abgesehen kann man sich die Info auf welchen Port/Adresse ein Socket gebunden ist vom System holen. Die Infos permanent in Membervariablen abzuspeichern ist also redundant.

Mag sein. Ich weiß zwar nicht wie, aber ich glaubs dir einfach mal.

Zurück zum Thema:

Ich mache das - in meinem aktuellen Projekt - im Prinzip so wie du, mit zwei (IMO unwesentlichen) Unterschieden:

1. Ich verwende nicht boost::signals(2) sondern was selbstgestricktes
2. Ich hab keine public Member, dafür aber nen Getter der nen shared_ptr<Event> zurückgibt (Event ist bei mir das, was bei signals(2) das "signal" ist)

Ändert aber nix daran, dass man vollen Zugriff auf das "signal" (Event) hat.

Register/Unregister Funktionen führen IMO zu viel zu viel Code-Duplizierung. Einerseits muss man innerhalb der Klasse die ganzen Attach/Detach Funktionen schreiben. Andrerseits kann man auch ausserhalb der Klasse viel weniger Code wiederverwenden. Da es z.B. kein gemeinsames Interface gibt, kann man auch keine Guard-Klassen schreiben die ein Attach im Ctor und ein Detach im Dtor machen. Zu erlauben dass das "signal" (in dem Fall die Klasse mit den Attach/Detach Funktionen) zerstört wird, während noch Listener draufhängen, ist in der Variante auch nicht einfach.

In Summe sind es mir einfach zu viele Nachteile.

Das einzige was mich an der "signal freilegen" Variante stört, ist, dass man von ausserhalb der Klasse das "signal" triggern kann ( node.value_changed(); ). OK, muss man halt einfach nicht machen. In grösseren Projekten, mit z.T. mässig disziplinierten Mitarbeitern, könnte das aber ein echter Nachteil sein.

Wenn man eine selbstgebackene Implementierung schreibt, könnte man das allerdings umgehen, indem man den Teil wo sich die "Listener" draufhängen können aus dem signal "raustrennt".

Grob skizziert:

class connection_point
{
public:
    connection attach(...);
    void detach(connection c);

// ...
// vermutlich wird hier ein
    friend class event;
// angebracht sein
};

class event
{
public:
    void fire();
    connection_point& get_connection_point() const;

// ...
};

class foo
{
public:
    connection_point& value_changed()
    {
        return m_value_changed_event.get_connection_point();
    }

    int get_value() const { return m_value; }
    void set_value(int val)
    {
        if (val != m_value)
        {
            m_value = val;
            m_value_changed_event->fire();
        }
    }

private:
    int m_value;
    event m_value_changed_event;
};