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?
4. How has the API changed from Boost.Signals version 1.34?

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?
	Yes, if the ThreadingModel template parameter of the signal is set to `boost::signalslib::multi_threaded`, or if it is set to `boost::signalslib::auto_threaded` and boost has detected thread support in the compiler's current translation mode. If you use `boost::signalslib::multi_threaded`, you will also have to link to libboost_thread.
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 a conflict with the `boost::signals` namespace. For thread_safe_signals, `boost::signals` is actually just a namespace alias to `boost::signalslib`. So by always using the namespace `boost::signalslib` instead of `boost::signals` in your code, you can avoid any conflict with the Qt `signals` macro. Alternatively, for Qt 4.1 and later the `signals` and `slots` macros 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/thread_safe_signals /usr/local/include/boost-1_33_1/ # ...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.
4.	How has the API changed from Boost.Signals version 1.34?
	In summary, the following changes have been made to the signals API: Automatic connection management is achieved through the use of `shared_ptr`/`weak_ptr` and `slot::track`(), as opposed to the old `boost::trackable` base class. The `slot` class takes a new `Signature` template parameter, is useable as a function object, and is generally more featureful. The `last_value` combiner throws an exception instead of producing undefined behavior when used with no slots connected (except for its specializations which do require any slots to be connected). An additional specialization last_value<`optional`<T> > (which does not throw) has been added. The `signal` class has an additional template parameter for specifying the threading model. The `signal::combiner()` method, which formerly returned a reference to the signal's combiner has been replaced by `signal::combiner` (which now returns the combiner by value) and `signal::set_combiner`. User-defined combiners are now expected to handle the possibility of a slot throwing an `expired_slot` exception due to automatic disconnection. `boost::visit_each`, which was used to find `boost::trackable` objects, is gone. Connections no longer have `block()` and `unblock()` methods. Blocking of connections is now accomplished by creating `shared_connection_block` objects. Support for postconstructors (and predestructors) on objects managed by `shared_ptr` has been added with `deconstruct_ptr`, `postconstructible`, and `predestructible`. This was motivated by the importance of `shared_ptr` for the new connection tracking scheme, and the inability to obtain a `shared_ptr` to an object in its constructor. The namespace `boost::signals` has been renamed `boost::signalslib` to avoid conflict with Qt's signal macro. For backward compatibility, a `boost::signals` namespace alias is provided.