# Boost.Signals Frequently Asked Questions

## Q: 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.

## Q: 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. Boost.Signals will support thread safety in the future.

## Q: 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. Although this is a problem with Qt and not Boost.Signals, a user can use the two systems together by 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;
      }

Redefining `BOOST_SIGNALS_NAMESPACE` breaks link compatibility with modules compiled using different `BOOST_SIGNALS_NAMESPACE` identifiers.

Last modified: Fri Oct 11 05:41:18 EDT 2002