| Home | Libraries | People | FAQ | More

## Frequently Asked Questions

1. Don't noncopyable signal semantics mean that a class with a signal member will be noncopyable as well?
2. Is Boost.Signals thread-safe?
3. How do I get Boost.Signals to work with Qt?

1. | Don't noncopyable signal semantics mean that a class with a signal member will be noncopyable as well?
| No. The compiler will not be able to generate a copy constructor or copy assignment operator for your class if it has a signal as a member, but you are free to write your own copy constructor and/or copy assignment operator. Just don't try to copy the signal.
2. | Is Boost.Signals thread-safe?
| No. Using Boost.Signals in a multithreaded concept is very dangerous, and it is very likely that the results will be less than satisfying. Even trying to invoke the same signal from two different threads is dangerous. Although we would like to make Signals thread-safe, it is unlikely to happen without help from other developers.
3. | How do I get Boost.Signals to work with Qt?
| When building with Qt, the Moc keywords `signals` and `slots` are defined using preprocessor macros, causing programs using Boost.Signals and Qt together to fail to compile. For Qt 4.1 and later, This behavior can be turned off in Qt on a per-project or per-file basis with the `no_keywords` option. This works with out-of-the-box builds of Boost and Qt. You do not need to re-configure, re-build, or duplicate existing libraries. For a project where you want to use both Boost.Signals and Qt Signals and Slots, the relevant part of your .pro file might look like this:
    CONFIG      += no_keywords # so Qt won't #define any non-all-caps `keywords'
    INCLUDEPATH += . /usr/local/include/boost-1_33_1/
    macx:LIBS   += /usr/local/lib/libboost_signals-1_33_1.a  # ...your exact paths may vary
Now you can mix Boost.Signals and Qt Signals and Slots in the same files, and even within the same class or function. You will have to use the upper-case versions of Qt macros in your own code. See the article A Deeper Look at Signals and Slots [off-site] for more complete examples and a survey of the strengths of the two systems.

Older versions of Qt did not provide a reliable mechanism for avoiding these unfriendly, all lower-case `keyword'-like macros. Although this is a problem with Qt and not Boost.Signals, a user can use the two systems together with a little extra effort. There are two ways to do this:

The first way involves defining the `BOOST_SIGNALS_NAMESPACE` macro to some other identifier (e.g., `signalslib`) when building and using the Boost.Signals library. Then the namespace of the Boost.Signals library will be `boost::BOOST_SIGNALS_NAMESPACE` instead of `boost::signals`. To retain the original namespace name in translation units that do not interact with Qt, you can use a namespace alias:

      namespace boost {
        namespace signals = BOOST_SIGNALS_NAMESPACE;
      }

The second way, provided by Frank Hess, involves creating a header `signalslib.hpp` that contains the following code:

    #ifdef signals
    #error "signalslib.hpp must be included before any qt header"
    #endif

    #include <boost/signal.hpp>
    namespace boost
    {
      namespace signalslib = signals;
    }

This header must be included before any Qt headers. Once it has been included, you can refer to the Signals library via the namespace `boost::signalslib`. This option is preferable to the first option because it can be used without recompiling the Signals library binary.

Last revised: November 03, 2006 at 19:45:40 GMT | Copyright © 2001-2004 Douglas Gregor