RE: [boost] Re: Signal/slot library

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
to impliment
> a Qt-like system in C++. The fact that they introduced a
preprocessing stage
> implies that there would be a lot of repetitive, error-prone hand
coding
> 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
MOC.

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.

--Karl