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.

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.

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 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.