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