Slots and signals: Listening to a value
I developed some classes which had similar functionality to slots and signals and now I want to transition to using slots and signals. I often find myself in the situation of wanting to listen to changes of a value type variable. I had a templated class called ConcreteObservable which encapsulated a get/set-able value and provided ways of listening to changes in the value. I.e. ConcreteObservable<bool> was a bool which you could get, set and listen to. I couldn't find anything corresponding in slots and signals so I wrote a small class - see end of post - which provides this functionality. I have a few questions regarding this: 1. Does the idea of a listenable value seem sound to you or do you see any problems? 2. Is there any existing boost code that already provides this functionality? 3. Do you see any problems with my implementation? 4. Do you have a better naming suggestion? Is signalling (user code would read signalling<bool>), listenable or signal_value perhaps better? template <class T> class signalling_value { public: signalling_value() : mValue(boost::value_initialized<T>()) {} signalling_value(const T& t) : mValue(t) {} void set(const T& value) { if (value != mValue) { mValue=value; mSignal(mValue); } } const T& get() const { return mValue; } template<class Slot> boost::signals::connection connect(const Slot& slot) const { return mSignal.connect(slot); } template<class Slot> boost::signals::connection connect(int order, const Slot& slot) const { return mSignal.connect(order, slot); } template<class Slot> void disconnect(const Slot& slot) const { mSignal.disconnect(slot); } private: T mValue; mutable boost::signal<void (const T&)> mSignal; };
On May 20, 2007, at 3:06 PM, Johan Torp wrote:
I often find myself in the situation of wanting to listen to changes of a value type variable. I had a templated class called ConcreteObservable which encapsulated a get/set-able value and provided ways of listening to changes in the value. I.e. ConcreteObservable<bool> was a bool which you could get, set and listen to.
1. Does the idea of a listenable value seem sound to you or do you see any problems?
Looks good to me. You might consider a few minor additions: - A copy constructor for signalling_value, that just copies the underlying value - A copy assignment operator for signalling_value, that just copies the underlying value - A conversion to const T& (same functionality as get) - An assignment operator that takes a const T& (same functionality as set)
2. Is there any existing boost code that already provides this functionality?
Not that I know of.
3. Do you see any problems with my implementation?
Looks good!
4. Do you have a better naming suggestion? Is signalling (user code would read signalling<bool>), listenable or signal_value perhaps better?
Did you consider "observable_value"? Or even just "observable"? - Doug
Johan Torp wrote:
I developed some classes which had similar functionality to slots and signals and now I want to transition to using slots and signals.
I often find myself in the situation of wanting to listen to changes of a value type variable. I had a templated class called ConcreteObservable which encapsulated a get/set-able value and provided ways of listening to changes in the value. I.e. ConcreteObservable<bool> was a bool which you could get, set and listen to.
Your idea is essentially a 'property' whose change in value triggers a notification event. Both Java and dotnet have such functionality combined with the idea of Javabean properties in the former and dotnet component properties in the latter. I have worked on my own with the idea of a C++ 'property', but not with enough personal satisfaction to put it in the sandbox or submit it to Boost. Reece Dunn, I believe, has submitted his own idea of a C++ 'property' as an implementation to the sandbox in the past. Obviously notifiers as events can be built into the idea of a C++ 'property' whenever the property changes and Java goes so far as to actually build into their idea of a Javabeans 'property' the idea of being able to cancel the change before it happens by an event ( signal ) listener ( slot ). I do not think the idea of an event whenever a 'property' changes should be part of the signals library itself but it can, and should IMO, use the signals library whenever the change occurs. I think the idea itself of a signalled 'property' change belongs in its own separate implementation, since the signals library is sufficient enough providing just the notion of signals and slots ( or events and handlers as others may call it ).
participants (3)
-
Douglas Gregor -
Edward Diener -
Johan Torp