| Trolltech Home | Qt-interest Home | Recent Threads | All Threads | Author | Date | |
| All threads index page 2 | |
There's a known problem when trying to use both Qt and Boost's Signals
library: Boost has a boost::signals namespace, while Qt has a signals macro
definition, doing:
#define signals protected
Last weekend I mailed a workaround to Douglas Gregor, the author of
Boost.Signals: instead of doing #include <boost/signal.hpp>, include the
following file, whenever you want to use Boost's signals:
/////////////////////////////////////////////////////////////
// signalslib.hpp
#ifndef SIGNALSLIB_HPP_INCLUDED
#define SIGNALSLIB_HPP_INCLUDED
#if defined(signals) && defined(QOBJECTDEFS_H) && \
!defined(QT_MOC_CPP)
#undef signals
#define signals signals
#endif
#include <boost/signal.hpp>
namespace boost
{
namespace signalslib = signals;
}
#if defined(signals) && defined(QOBJECTDEFS_H) && \
!defined(QT_MOC_CPP)
#undef signals
// Restore the macro definition of "signals", as it was
// defined by Qt's <qobjectdefs.h>.
#define signals protected
#endif
#endif
/////////////////////////////////////////////////////////////
As you can see, this header file "undefines" Qt's macro definition of
"signals" at the beginning, and restore its definition at the end. In
between, it provides an alias to boost::signals, named boost::signalslib.
The workaround is an update to the one originally provided by Frank Hess at
www.boost.org/doc/html/signals/s04.html#id1633734 It has the advantage
that, unlike the original workaround, this header does not necessarily need
to be included before any Qt headers.
Please let me know if I have overseen any particular issue! Otherwise,
enjoy the workaround :-)
Kind regards,
--
[ signature omitted ]
On Tuesday 15 January 2008 10:57:35 Niels Dekker - no return address wrote: > There's a known problem when trying to use both Qt and Boost's Signals > library: Boost has a boost::signals namespace, while Qt has a signals macro > definition, doing: > Â #define signals protected Solution: #define QT_NO_KEYWORDS and use Q_SIGNALS and Q_SLOTS instead of signals and slots in your programs. See http://trolltech.com/developer/notes/changes/changes-4.1.0/ -- [ signature omitted ]
Attachment:
signature.asc
Description: This is a digitally signed message part.
Thiago Macieira wrote: > #define QT_NO_KEYWORDS > and use Q_SIGNALS and Q_SLOTS instead of signals and slots in your > programs. > > See http://trolltech.com/developer/notes/changes/changes-4.1.0/ Thanks, Thiago! Unfortunately it doesn't work on Qt 3, and there are still a lot of Qt 3 based projects around, so I think the workaround I presented still makes sense. :-) Kind regards, Niels -- [ signature omitted ]
In my original posing I suggested a new version of "signalslib.hpp", so that
one could replace #include <boost/signal.hpp> by #include "signalslib.hpp",
as a workaround to the problem of having both Qt signals and boost::signals.
"signalslib.hpp" had a few lines saying:
> #if defined(signals) && defined(QOBJECTDEFS_H) && \
> !defined(QT_MOC_CPP)
One of my collegues at LKEB (www.lkeb.nl) told me that the Qt 3 macro
QT_MOC_CPP appears to be replaced by QT_MOC_RUN, in Qt 4. Right? So would
it be better to add an extra test, !defined(QT_MOC_RUN) to the workaround?
As follows?
/////////////////////////////////////////////////////////////
// signalslib.hpp -- revision: added test on QT_MOC_RUN
#ifndef SIGNALSLIB_HPP_INCLUDED
#define SIGNALSLIB_HPP_INCLUDED
#if defined(signals) && defined(QOBJECTDEFS_H) && \
!defined(QT_MOC_CPP) && !defined(QT_MOC_RUN)
#undef signals
#define signals signals
#endif
#include <boost/signal.hpp>
namespace boost
{
namespace signalslib = signals;
}
#if defined(signals) && defined(QOBJECTDEFS_H) && \
!defined(QT_MOC_CPP) && !defined(QT_MOC_RUN)
#undef signals
// Restore the macro definition of "signals", as it was
// defined by Qt's <qobjectdefs.h>.
#define signals protected
#endif
#endif
/////////////////////////////////////////////////////////////
Or could those tests on QT_MOC_CPP and QT_MOC_RUN be safely removed?!? I
mean, does the MOC-run care at all about how the signal macro is defined?
Kind regards, Niels
--
[ signature omitted ]
There's a known problem when trying to use both Qt and Boost's Signals
library: Boost has a boost::signals namespace, while Qt has a signals macro
definition, doing:
#define signals protected
Last weekend I mailed a workaround to Douglas Gregor, the author of
Boost.Signals: instead of doing #include <boost/signal.hpp>, include the
following file, whenever you want to use Boost's signals:
/////////////////////////////////////////////////////////////
// signalslib.hpp
#ifndef SIGNALSLIB_HPP_INCLUDED
#define SIGNALSLIB_HPP_INCLUDED
#if defined(signals) && defined(QOBJECTDEFS_H) && \
!defined(QT_MOC_CPP)
#undef signals
#define signals signals
#endif
#include <boost/signal.hpp>
namespace boost
{
namespace signalslib = signals;
}
#if defined(signals) && defined(QOBJECTDEFS_H) && \
!defined(QT_MOC_CPP)
#undef signals
// Restore the macro definition of "signals", as it was
// defined by Qt's <qobjectdefs.h>.
#define signals protected
#endif
#endif
/////////////////////////////////////////////////////////////
As you can see, this header file "undefines" Qt's macro definition of
"signals" at the beginning, and restore its definition at the end. In
between, it provides an alias to boost::signals, named boost::signalslib.
The workaround is an update to the one originally provided by Frank Hess at
www.boost.org/doc/html/signals/s04.html#id1633734 It has the advantage
that, unlike the original workaround, this header does not necessarily need
to be included before any Qt headers.
Please let me know if I have overseen any particular issue! Otherwise,
enjoy the workaround :-)
Kind regards,
--
[ signature omitted ]