From: Karl Nelson (kenelson_at_[hidden])
Date: 2000-04-10 11:13:26
--- In boost_at_[hidden], "Hibbs, Philip" <philip.hibbs_at_t...> wrote:
> The MOC code is preprocessed to produce C++ code, so it's possible
> a Qt-like system in C++. The fact that they introduced a
> implies that there would be a lot of repetitive, error-prone hand
> involved in writing it all in C++, though.
MOC is C++ only in using tons of macros in ones code to change the
rules of the language is C++. I really don't see many systems
which require the user typing several hundred lines of interconnect
code by hand as feasable, which is exactly what Qt system is without
Further many of the macros are unnecessary. The are placed there
simply to make things look pretty. The worst of these is the
keyword "emit". emit isn't looked at by MOC nor is it used in
the code. It is simply inserted in front of signals to make
it look pretty. This has the horrible side effect of wiping
out use of emit inside classes where it may be needed.
SigC for example has a method named emit which it can't use
with Qt because of this conflict. Such pointless use of macros
should be shamed, not touted as good C++ code.
Also Qt signal systme is tied to Qt library classes. This is
certainly overcomable. Qt classes are a full rewrite of
STL only without use of the standard. This in itself should
show that they aren't into working with a standard. Qt signal
system it tied to the Object completely. A signal can not exist
outside of an object. SigC and the proposed system both
have signals as independent concepts. Since in essence
a signal is just a list of closures the only
reason for it to be in the Object is to secure a smaller
size. However, the exact same thing can be achieved with a
map<> and an independent signal<>. Thus a signal primative as
done by SigC is more flexible.
Moreover Qt lacks the concept of a closure. Signal connections
are formed at the point of the signal and function with a macro.
This disallows systems where the function and the signal are
not available in the same peice of code. It is much better to
have a closure concept which allows the user to create the
closure in one place and pass it around where it may be called
or added to a signal.
Last, Qt signal system is horribly slow. It is tied to the concept
of a GUI library so really it has no reason to be fast. If however
it were used in general programming sense, it would be unacceptable.
I have never figured out where the slowness is so I can't say
that it isn't fixable.
For all these reasons I would think that a Qt type system would
not be acceptable from a standard library prospective.
I don't mean to say by this that SigC is perfect nor acceptable
to boost. It sufferes a major problem with slots becoming invalid.
Since some of the data stored internally is not copiable and there
is a 1 parent restriction, you can't place a slot(closure) on
multiple signals. The is currently some restructuring needed
to fix the problem. I wouldn't consider it suitable for submission
to a standard until all such issues are resolved.
SigC would be a better starting point to examine issues that Qt.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk