From: fmhess_at_[hidden]
Date: 2007-06-08 13:31:58
Author: fmhess
Date: 2007-06-08 13:31:57 EDT (Fri, 08 Jun 2007)
New Revision: 4498
URL: http://svn.boost.org/trac/boost/changeset/4498
Log:
Updated thread_safe_signals FAQ wrt using with Qt.
Text files modified:
sandbox/libs/thread_safe_signals/doc/faq.xml | 60 ++++++++-------------------------------
1 files changed, 13 insertions(+), 47 deletions(-)
Modified: sandbox/libs/thread_safe_signals/doc/faq.xml
==============================================================================
--- sandbox/libs/thread_safe_signals/doc/faq.xml (original)
+++ sandbox/libs/thread_safe_signals/doc/faq.xml 2007-06-08 13:31:57 EDT (Fri, 08 Jun 2007)
@@ -24,8 +24,10 @@
</question>
<answer>
<para>Yes, if the ThreadingModel template parameter of the signal is set to
- boost::signals::multi_threaded. If you use thread-safe signals
- in your code, you will also have to link to libboost_thread.</para>
+ <code>boost::signals::multi_threaded</code>, or if it is set to
+ <code>boost::signals::auto_threaded</code> and boost has detected thread support
+ in the compiler's current translation mode. If you use <code>boost::signals::multi_threaded</code>,
+ you will also have to link to libboost_thread.</para>
</answer>
</qandaentry>
<qandaentry>
@@ -35,10 +37,16 @@
<answer>
<para>When building with Qt, the Moc keywords
<code>signals</code> and <code>slots</code> are defined using
- preprocessor macros, causing programs using Boost.Signals and
- Qt together to fail to compile.</para>
+ preprocessor macros, causing a conflict with the <code>boost::signals</code>
+ namespace. For thread_safe_signals, <code>boost::signals</code> is actually
+ just an alias to <code>boost::signalslib</code>. So by always using the
+ namespace <code>boost::signalslib</code> instead of
+ <code>boost::signals</code> in your
+ code, you can avoid any conflict with the Qt <code>signals</code> macro.
+ </para>
- <para><emphasis>For Qt 4.1 and later</emphasis>, This behavior
+ <para>Alternatively, for <emphasis>Qt 4.1 and later</emphasis>
+ the <code>signals</code> and <code>slots</code> macros
can be turned off in Qt on a per-project or per-file basis
with the <code>no_keywords</code> option. This works with
out-of-the-box builds of Boost and Qt. You do not need to
@@ -62,48 +70,6 @@
complete examples and a survey of the strengths of the two
systems.</para>
- <para><emphasis>Older versions of Qt</emphasis> 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:</para>
-
- <para>The first way involves defining
- the <code>BOOST_SIGNALS_NAMESPACE</code>
- macro to some other identifier (e.g., <code>signalslib</code>)
- when building and using the Boost.Signals library. Then the
- namespace of the Boost.Signals library will be
- <code>boost::BOOST_SIGNALS_NAMESPACE</code> instead of
- <code>boost::signals</code>. To retain the original namespace
- name in translation units that do not interact with Qt, you
- can use a namespace alias:</para>
-
- <programlisting>
- namespace boost {
- namespace signals = BOOST_SIGNALS_NAMESPACE;
- }
-</programlisting>
-
- <para>The second way, provided by Frank Hess, involves
- creating a header <code>signalslib.hpp</code> that contains
- the following code:</para>
-
- <programlisting>#ifdef signals
-#error "signalslib.hpp must be included before any qt header"
-#endif
-
-#include <boost/signal.hpp>
-namespace boost
-{
- namespace signalslib = signals;
-}</programlisting>
-
- <para>This header must be included before any Qt headers. Once
- it has been included, you can refer to the Signals library via
- the namespace <code>boost::signalslib</code>. This option is
- preferable to the first option because it can be used without
- recompiling the Signals library binary. </para>
</answer>
</qandaentry>
</qandaset>