[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-freeqt
Subject:    Re: [freeqt] Relay++ library is good for you :)
From:       Olivier Galibert <galibert () pobox ! com>
Date:       1998-09-28 1:44:43
[Download RAW message or body]

On Sun, Sep 27, 1998 at 05:19:55PM +0200, Christian Boos wrote:
> |1. Signals   and slots   are  regular  member   functions.  The   only
> |   requirement  is that the classes  which  will implement signals and
> |   slots must inherit  from a common 'Relay' class,  hence the name of
> |   the    library.  Because  signal  and    slots  are regular  member
> |   functions, their usage  is type-safe, and  this safeness is ensured
> |   at compile-time.

This is good.  Too bad it's impossible with  Qt's syntax.  The current
code does the check at connection time.


> |2. The static type-checking is  provided  by templates and there's  no
> |   need for a preprocessor.

Ditto, good but impossible with Qt's syntax.


> |4. The signal/slot library is  meant to be fully reentrant: concurrent
> |   threads can safely access the signal/slots in mutual exclusion, and
> |   even  a particular thread    can  reenter the  signal/slot  library
> |   anytime (useful when one wants to connect, disconnect, or even emit
> |   a signal from a slot).

This also is  provided with the current code.   BTW,  what happen when
you emit a signal which has two or more slots connected to itself, and
the first  slot  happens   to  disconnect  the  second  one?   Magna's
generated   code ensures  that  the list  of  slots  called is the one
existing at trigerring time.


> |5. The   signal/slot communications   support  an asynchronous   mode,
> |   facilitating real-time responsiveness when writing GUIs.

Interesting.


> |6. Lastly, this implementation is meant to [be] resource friendly and fast
> |   (thanks to the STL).

It actually is slightly heavier than magna's generated code.


> Currently none. It would require to do the following:
> - get rid of the magna stuff

See other mail.  Magna won't  go without something equivalent in terms
of using Qt's standard syntax replacing it.


> - rewrite QObject; basically it should inherit from Relay, and RTTI
>   should be done, well, with REAL rtti (*)

Real  RTTI doesn't provide an  access to class  names.  Such access is
required for  the theme  implementation.   We may be  able to overcome
that  by  changing   the  theme interface   to use    partial template
specialisation, but I   don't trust current  compilers (this  includes
egcs 1.1) to cope well with that and shared libraries.

Also, while I  agree that RTTI should  be done with  real  RTTI, it is
_not_ done  with real RTTI.   We _must_  provide  the current  syntax.
That's a quasi-clone we're working on, remember?


> A very interesting point is that the adoption of the Relay++ library for
> Harmony would make its signal/slot implementation RADICALLY different
> than the Qt one. The syntax will also be different, but not too much.

You're radically  wrong.  Magna is more  different for  Qt's code than
yours.  Why?   You use trigger(),  which is an almost exact equivalent
to   Qt's   activate(),  while  a    generic    signal  activator   is
near-to-impossible to write with magna's code.


> (*) This leads me to a general remark. Qt has been designated in the
> early 90 (am I right?), and since then, the C++ language has evolved
> quite much. I found that many things in Qt's design are now obsolated
> by what modern C++ can do (rtti, the string-based signal/slots,
> and the ad-hoc collections come to mind). 

I agree with  that.  But once again,  we're cloning first, redesigning
second.


> Integration with Gtk--
> ----------------------
> 
> Tero, I guess you will be interested with the very small memory
> footprint of the Relay class : 60 bytes, when nothing is connected.
> Each active connection is at least 64 bytes, add another ~60 bytes for 
> housekeeping. 

Magna:  STL-implementation dependant of course,  but  probably 4 bytes
per existing signal with no connection and an  additional 12 bytes per
connection (afaik, pointer-to-member-functions  are 8 bytes).  Oh, add
4 bytes for the first connection for a given signal.

Actually, the structure  is   an array of   void  * (one  per  signal)
pointing to  lists of (object,  method pointer) pairs.   Everything is
allocated on a as-needed basis.

The only mutex used is the provided QObject mutex,  and hence its cost
is negligible.


> This cost is almost essentially due to the mutexes. If you want to get
> rid of MT-support, you'll get an even lighter implementation...
> (actually getting rid of the MT-support throws aways 70% of the
> code... and 95% of its complexity!)

This is the  problem  with centralized structures.   Magna's generated
code was designed  to be MT-clean  from  the start, and hence  is very
efficient with a very low MT-induced overhead.

A thing  I don't have time  to test: do   you handle polymorphic slots
(like  QWidget::update)    and    default  values  in     slots  (like
QWidget::repaint)?

  OG.

[prev in list] [next in list] [prev in thread] [next in thread]