This is a Signal Slot implementation for C++ -------------------------------------------- It is GPL licensed. see file LICENSE. VERSION 0.0.1 2000-05-09 VERSION 0.0.0 1997-08-25 -------------------------- first read the old text from 1997. at the end of the document you see my new updates. 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-- to include my sigslot system :) feel free to mail me. ********** UPDATE 2000-05-09 hi. when reading the previous parts, keep in mind that the past days have been different to our situation nowadays. QT quite drastically changed their strategies. GTK-- is using libsigc++ (http://libsigc.sourceforge.net/) and not my implementation. the reason i started on this again, is that i am now developing signals and slots over networks. (not part of THIS package) so i fixed some problems in the old version. (it didn't compile anymore due to compiler changes.) cu erik -- Name: Erik Thiele \\\\ Email: erikyyy at erikyyy dot de o `QQ'_ IRC: erikyyy / __8 WWW: http://www.erikyyy.de/ ' `