Re: Events in C++
Hi,
Wim wrote:
I'm looking for some help on how to best implement an observer pattern in
C++. I have an object that several objects will register with, and on
each event, all the objects are notified.
this is an interesting topic, but since events are usually used in
multi-threaded environments you only touched the surface so far.
Here is a simple example of the code I'm using now:
[...]
I would recommend to encapsulate the list of listener in the generator
too, since this pattern is likely to be repeated.
In my situation, ExampleProcessor typically either stores the data, or
does nothing with it. I don't like the fact that it has to do the copy
itself, it's just too easy to forget!
I though about passing an auto_ptr like this: virtual void onData
(auto_ptr<ExampleData> data) But if I do that, I have to copy the
data for each listener, while typically, only 1 listener will need to
store it. Perhaps some smarter version of auto_ptr is handy here? Any
comments and hints on how to do this best are more than welcome!
Don't use auto_ptrs here for the reasons you already mentioned. Raising
an event is typically a synchronous from the generators point of view.
So it is straight forward that the generator holds the ownership of the
parameters wherever hi like (local, static, dynamic storage).
First of all you should check your needs.
- Should your observer be thread-safe? - Most likely yes.
generators and listeners are usually in a different thread. And
addListener is usually called from the listener's thread, while fire is
called from the generator's thread.
- Do you want a strong or a weak reference from the generator to the
listeners? In other words: should a listener automatically deregister
from the generator when it is destroyed. I recommend yes.
- Are there dependent objects who's lifetime should be influenced by the
registration?
- Is it allowed that a listener's lifetime exceeds the lifetime of the
generator where it is registered?
- Should one listener instance be usable for more than one generator at
the same time?
I recommend no. It just simplifies things.
- What should happen when an event is fired while a listener is going to
deregister?
1. wait for the other to complete.
This is likely to cause deadlocks. At least if the underlying mutex is
not recursive, because it is a common practice to deregister from a
generator within the callback code. Furthermore the listeners must not
acquire any other mutex within the receive function. This ist difficult
to achieve.
2. proceed.
This has the risk that the listener's receive method still may depend on
objects whose lifetime ends immediately after the deregistration.
3. some compromise between 1 and 2.
- Is it acceptable to have one mutex instance for each generator
instance? - I recommend not.
If not you need some global critical mutex object which must be
initialized before any listener is registered. This may be difficult if
the registration is done from the constructor of static objects.
- Do you need a second parameter to the receive function that comes from
the listener's instance?
I recommend yes. While this is strictly speaking not required because
you always can derive from the listener, it is more convenient because
you do not always have to subclass for each use pattern. A template
subclass of a non-template base is a good solution.
Let me know if you want example coding. I have implementations for this
purpose, but they are a bit too long to be copied and fully explained
here without demand.
Marcel