[signals2] 'static initialisation fiasco' issues

I am trying to build a modular system in which independently compilable cpp files communicate by signals, but otherwise know nothing about each other at compile time. e.g. #include "TheRangeFinderSignals.h" #include "TheProximitySensorSignals.h" class TerrainMap { ....connect to signals and send signals.... } TheSingletonTerrainMap; This all works very well except that TerrainMap needs to connect to signals from its constructor. The signals are static global objects which serve to exchange data between the independent modules. Unfortunately I have fallen foul of C++ static initialisation problems. I cannot be certain that the static signal objects will be created before the modules that use them. The C++ FAQ recommends wrapping the static variables in a function: e.g. EventSignal<void (Gray16Image)> &OnNewDepthFrameAvailable() { static EventSignal<void (Gray16Image)> *zzz = new EventSignal<void(Gray16Image)>; return *zzz; } This works but it is syntactically messy to use. All uses of OnNewDepthFrameAvailable must be replaced with OnNewDepthFrameAvailable(). i.e OnNewDepthFrameAvailable().connect(...) OnNewDepthFrameAvailable()(theNewFrame); Is there any way to avoid this ? It is not easy to hide the detail. I wanted to define a template class to encapsulate the idiom and eliminate the need for the extra parenthesis. e.g. SafeStatic< EventSignal<void (Gray16Image)> > OnNewDepthFrameAvailable; template<type T> class SafeStatic { T *obj; void operator()(theArgsToSignal) { if (!obj) obj = new T; obj(theArgsToSignal); } }; The problem is that the Signal template defines a variable arity and signature operator(). I have no idea how to provide the same signature on the function call operator of SafeStatic Any other way around this problem ?

----- Original Message ----- From: "elpidio valdez" <elpidiovaldez6@gmail.com> To: <boost@lists.boost.org> Sent: Tuesday, September 27, 2011 8:39 PM Subject: [boost] [signals2] 'static initialisation fiasco' issues
This all works very well except that TerrainMap needs to connect to signals from its constructor. The signals are static global objects which serve to exchange data between the independent modules. Unfortunately I have fallen foul of C++ static initialisation problems. I cannot be certain that the static signal objects will be created before the modules that use them.
Maybe you could consider doing less during construction at loadtime. I usually define all static objects, during construction they only register themselves (or some initialisation functions) to some static repository. Then at runtime, before making use of those objects, everything gets initialised by calling some static function "InitializeAllTheStuff();" which inspects the repository and does what has to be done. So all objects are for sure created before you initialise. De repository is about the only object that needs to be wrapped inside a function, and it doesn't show up in the interfaces. Instead however, the initialisation function pops up in you interface and it has to be called once. IMO that's not too bad. regards Wouter
participants (2)
-
elpidio valdez
-
Wouter Van Alboom