[thread_safe_signals] changing the namespace used
Hello, In trying to use thread_safe_signals with Dataflow.Signals, I did the following before including the headers to cause thread_safe_signals to use the boost::signals namespace instead of boost::signalslib (I needed this because Dataflow.Signals adds to the boost::signals namespace): #define signalslib signals #define signals signals The first line was to change the namespace used, and the second to prevent thread_safe_signals from aliasing boost::signals to itself. This worked for gcc on OS X, but I just found out that msvc 2005 express chokes on it (in some preprocessing file iteration loop). Is there a better solution for this? Thanks, Stjepan
On Monday 08 September 2008 19:33, Stjepan Rajko wrote:
Hello,
In trying to use thread_safe_signals with Dataflow.Signals, I did the following before including the headers to cause thread_safe_signals to use the boost::signals namespace instead of boost::signalslib (I needed this because Dataflow.Signals adds to the boost::signals namespace):
Isn't putting dataflow library stuff in boost::signals wrong (as in, against boost policy)? Shouldn't your library stay out of other library's namespaces? Is there any reason socket_sender (for example) can't be in boost::dataflow::signals instead of boost::signals?
This worked for gcc on OS X, but I just found out that msvc 2005 express chokes on it (in some preprocessing file iteration loop). Is there a better solution for this?
I don't have any specific suggestions for workarounds, but FYI if thread_safe_signals ever comes up for review, my plan is to ditch the signals namespace alias which was attempting to provide some backwards compatibility. I plan to move everything into a "signals2" namespace, and rearrange the headers to conform to boost policy.
On Mon, Sep 8, 2008 at 5:38 PM, Frank Mori Hess <fmhess@speakeasy.net> wrote:
On Monday 08 September 2008 19:33, Stjepan Rajko wrote:
Hello,
In trying to use thread_safe_signals with Dataflow.Signals, I did the following before including the headers to cause thread_safe_signals to use the boost::signals namespace instead of boost::signalslib (I needed this because Dataflow.Signals adds to the boost::signals namespace):
Isn't putting dataflow library stuff in boost::signals wrong (as in, against boost policy)? Shouldn't your library stay out of other library's namespaces? Is there any reason socket_sender (for example) can't be in boost::dataflow::signals instead of boost::signals?
I could have gone either way, but when I was developing Dataflow.Signals during Google summer of code I asked Doug Gregor (who was my mentor) what he thought and he suggested I put things in boost::signals because the Dataflow.Signals layer was so closely tied to Boost.Signals. That choice had some other advantages, for example the connect function could be reached via ADL when one of the arguments was a signal (even when none of the arguments were Dataflow.Signals components).
This worked for gcc on OS X, but I just found out that msvc 2005 express chokes on it (in some preprocessing file iteration loop). Is there a better solution for this?
I don't have any specific suggestions for workarounds, but FYI if thread_safe_signals ever comes up for review, my plan is to ditch the signals namespace alias which was attempting to provide some backwards compatibility. I plan to move everything into a "signals2" namespace, and rearrange the headers to conform to boost policy.
In that case, I can eventually move Dataflow.Signals components to their own namespace, as you suggested. Kind regards, Stjepan
participants (2)
-
Frank Mori Hess -
Stjepan Rajko