Boost logo

Boost :

Subject: Re: [boost] [thread_safe_signals] changing the namespace used
From: Stjepan Rajko (stipe_at_[hidden])
Date: 2008-09-08 20:54:06


On Mon, Sep 8, 2008 at 5:38 PM, Frank Mori Hess <fmhess_at_[hidden]> 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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk