14 Aug
2009
14 Aug
'09
2:29 p.m.
On Fri, 14 Aug 2009, Pedro Lopez-Cabanillas wrote:
[snip]
Not exactly. You can manipulate run-time connections with either library.
libsigc++ requires that the types of the connections being made at runtime
are already known at compile time.
Qt allows you to make connections between signals and slots whose types
are not known until runtime.
This difference is generally not significant to an application designer.
The only place I know that this ability is being utilized is in KDE where
the UI's are being created at run-time from an XML file specification.
And with a little planning, you could probably do something similar with
sigc++.
HTH,
Gabriel
gtkmm is
signal/slot based too, but because of its closer integration
with C++ idioms, this particular issue doesn't arise too much. you
don't need a pre-processor to use libsigc++
Of course you need a pre-processor to use libsigc++. The pre-processor is a
standard part of the C++ (or plain C) compilation chain, for instance
the "cpp" program for the GCC compiler. It takes care of expanding macros,
compile directives and conditional compilation.
Maybe you are thinking about the Qt's "moc" code generator tool. It reads a
MOC is not a pre-processor because it doesn't
replace any text in the original
[snip]
moc is processing source code by scanning it and then generating code that
will be fed to the compiler. This is a preprocessor.
I love Qt, really... but having to use moc is annoying. I'm not alone in
this. Plus, syntax highlighters sometimes choke on Qt's syntax.
signals &
slots are a callback mechanism too. they just hide it from
the programmer with a different kind of abstraction (when this signal
is "emitted", call the following "slot"). its all just syntactic
sugar.
The main (functional) difference between the two systems is that Qt's signals
and slots can be manipulated at runtime, while you can't do the same with
libsigc++, that freezes the connections at compile time. Manipulate means