This is a follow-up to this question, which resulted in major confusion on my side regarding forwarding of arguments. Advice regarding that should probably be given in my question on SO.
Overview
The classes below implement the observer pattern for use in an embedded system. My main need is to be able to connect sources of data (a GPS with position information, for example) to consumers (debugging over a serial line or a position widget). A Signal may have arguments, which are sent to the observers (zero or more Connections), which call a delegate (free function, static or non-static member).
The return values of any called function are discarded in the interface of AbstractDelegate, because the calling Signal shouldn't need to care about any return values. I didn't use std::function for this because it simply occupied too much the system`s available RAM.
Signals can be copied, because they would be used as object members. A class that contains a Signal member should not be non-copyable just because a Signal is present. I'm not sure if I want to support Connection members, please enlighten me if you have good advice about that.
Connections are created on the heap using two connect functions - one for free functions and static methods, one for non-static methods.
I didn't use an STL container for the Signal's connection list because I need control over memory allocation, and a Connection must be able to remove itself from the Signal's list. The result of these two (maybe wrong) thoughts is the intrusive linked list I implemented.
Signals can be blocked (block(), unblock()). If that is the case, no Connection will be notified. Connections can also be blocked individually.
The header
And how it's supposed to be used
My main concerns are about copy construction and assignment of Signals and Connections. I added those operations because I needed destructors for those classes (rule of three) - taking a look at the desctructors might also be a good idea.
I'm also interested in pitfalls I might have overlooked. I think I have made sure that deleting a Signal or a Connection does not leave any dangling pointers, but that might not be the only thing that can go wrong here.