Douglas Gregor wrote: [Setting up a signal with tracking support from within a constructor]
Does enable_shared_from_this help at all?
I don't think you can safely use it in a constructor to acquire a shared_ptr to yourself, right? It would go out of scope when the constructor exits and your object will be destroyed. One would have to provide a factory function, which is what Frank wanted to avoid. I have a few questions about your Signals implementation, which you could perhaps answer best: The templated signalN::disconnect allows disconnection by "slot", which the docs say elsewhere is difficult to achieve, because of the problem to compare the target function objects. The Boost Function agrees with this, but mentions that Signals knows "a way around it". Now what the implementation seems to do is to simply call operator== on the target function objects. That frankly leaves me somewhat confused. I understand that it should work when the functions are reference wrapped (which will be always the case when the slot target is a signal itself). We could simply mimic the original implementation, but I sure would feel better if I understood what it is going on. Does storing the combiner in Any really help fighting code bloat as mentioned under "Type Erasure" in the docs? It is only used in the signal template. It's copied and invoked, the former by utilizing the any copy constructor which is templated (resulting in more code for the heap storage, not in less) and the latter by using unsafe_any_cast, which effectively gives you a pointer to the original type and the actual invocation should therefor result in the same code. I would prefer storing the combiner directly to avoid the any-related heap allocations, but I don't have access to a large variety of compilers to check the code size differences. As a more general question, do you think that declaring trackable deprecated and only providing it for backwards-compatibility is a good solution? Regards Timmo Stange