Signal Slot implementation, C++

[Erik Thiele <erik unterland de>]

hi. this mail is sent both to the developers of the Linux Interface
Project and the developers of the GTK. it is related to GTK--, not to GTK,
however.

i have developed a Signal Slot implementation. I'd like it to be included
into LIP and GTK--  ;)  feel free to mail me.

this is the README file. it is also included in the distribution that is
attached to this mail. no need to save this mail. the distribution is
enough.

--------------------- snip

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!! THIS IS ALL MY CODE, ALL RIGHTS RESERVED !!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

(i am lazy now, GPL later!)

This is a Signal Slot implementation for C++
--------------------------------------------

VERSION 0.0.0   Mon Aug 25 21:21:01 CEST 1997
---------------------------------------------

Features:
---------

- no Precompiler needed
- debugging through signal calls possible
- defered and shot connects possible
- variable number of parameters
- type safety at COMPILETIME
- impossible connections are detected at COMPILETIME
- classes that use signals and slot do NOT need to be derived
  from some kind of super super class
- can be included in ANY existing application without major
  changes
- can COEXIST together with other signal slot implementations at
  the same time in the same program !
- if you use deferes connects, you have to add a call to
  mainQueue::run(); in your main event loop. All defered
  Signals will be delivered then.
- minimum amount of copies of objects while being transfered
  through the Signal Slot system.
  if you do a SHOT connect, no copy.
  if you do a DEFERED connect, one copy.
- only one slot is attached to a signal
  only one signal is attached to a slot
  (it is possible to extend the code, so that multiple connections
  per signal and slot are supported,
  but this is not the thing of most importance right now, I think)
- !!!!!!!!!!!!!! if a class that has the Slot is deleted, an
  eventually existing connection with a Signal is cut !!!!
  eventually defered waiting Signal deliveries are canceled !!!
  this feature is missing in some other implementations, but I
  think it's damn important !

why did I write this peace of code ?
------------------------------------
i am developing a textmode based GUI on DOS (uuargh...) therefore
i needed a signal slot implementation. so i wrote one. here
it is.
REMEMBER: this can be used for EVERYTHING, not just GUIs.

why do i support those defered connects ?
-----------------------------------------

if a widget emits a signal The_User_Pressed_The_Quit_Button() or
Game_Over() or I_am_of_no_use_anymore() then the receiver of
the signal might want to delete the widget. if you do this
with a normal signal slot system, the widget will be deleted
NOW (in the slot routine). when the slot routine is done, the
CPU will continue work right after the emission call of the signal
in the widget class, but the widget class doesn't exist anymore
this can lead into core dumps and you have to write terrible
workarounds (let someone else delete it later, or make the
widget modal, or just don't delete it)
with defered connects, the widget emits Game_Over() and the
call returns imediately. the signal is queued. now the program
will continue, until it is in the main event loop again.
there, mainQueue::run(); will be called, and NOW the signal will
be delivered. the widget is not on the calling stack now, and so
it is save for the receiver to do "delete the_widget;";
understand ?

eeeh. hmm. what shall i do now ?
--------------------------------

make
./evtest

this is what you do. afterwards, take a look at evtest.cpp
i hope it explains things.

General thoughts and who I am... (please read)
----------------------------------------------

My name is Erik Thiele. I have built a robot car on rtlinux
(linux with realtime extensions). it is able to navigate in a
room, and it drives around autonomously. See my homepage.
MANY pictures ;) I used a libQT program to control the car.
while doing so I found tons of bugs in libQT. the authors
said: "Yes this is a bug. it is fixed now. here is the patch.
You mustn't use the patch, the license forbids this"
this is the first thing i dislike about QT.
second is the license.
third is some design errors regarding processEvents();
and the lack of defered signals.
fourth: they do not release bugfixes.
fifth: after finally accepting that one of my bugs is a
horror bug that just renders the lib useless, they released
a bugfix version. but this version only fixes this horror bug,
all the other bugs aren't fixed.
sixth: the next version of the library will include not only
the bugfixes, but also new features, this means new bugs.
seventh: this way there will never be a stable QT, because
of the version release policy.
by the way: libQT is http://www.troll.no/
I am also interested in model submarines. see my homepage ;)
I think, a GUI is a fundamental thing. it must be bugfree.
it must be FREE. source must be available, it must be LGPL.
it must be good :)

i'd like GTK--
and LIP
to include my sigslot system :)

feel free to mail me.

--
EMAIL: erik@unterland.de                  \\\\
IRC:   erikyyy                            o `QQ'_
HP:    http://escape.unterland.de/~erik/   /   __8
                                           '  `
--------------------------- snip


--
EMAIL: erik@unterland.de                  \\\\
IRC:   erikyyy                            o `QQ'_
HP:    http://escape.unterland.de/~erik/   /   __8
                                           '  `

thisis it