On Wednesday 22 August 2007 21:18, Jake hall wrote:
I would like to hear peoples thought on a library i uploaded to the vault and maybe get it submitted for review. the libraries name is the EventHandler library, it can be found in the vault under home / Generic Programming / EventHandler.zip
i find it simple to use (well i wrote it so i should) but effective at adding almost .net style events to classes
I've never used .net events/delegates, but from a google search and a subsequent 60 second review of an article on them, they seem to cover the same ground as signals/slots. Am I way off base here?
I quickly googled signals/slots and found a website called http://doc.trolltech.com/3.3/signalsandslots.html which talkes about a class called "QObject", at the begining of the page they state there reasons for using signals/slots, which are ; doc.trolltech.com wrote:
Callbacks have two fundamental flaws. Firstly they are not type safe. We can never be certain that the processing function will call the callback with the correct arguments. Secondly the callback is strongly coupled to the processing function since the processing function must know which callback to call.
The EventHandler library enforces a type safety in the callback function pointers and you can also clone EventHandlers simply by event_handler<> * event = &anotherevent; so althout you need to know the function to call it doesnt have to be specified each time. these features minic (and in areas improve on) the .net feel of events.
Jake hall wrote:
On Wednesday 22 August 2007 21:18, Jake hall wrote:
I would like to hear peoples thought on a library i uploaded to the vault and maybe get it submitted for review. the libraries name is the EventHandler library, it can be found in the vault under home / Generic Programming / EventHandler.zip
i find it simple to use (well i wrote it so i should) but effective at adding almost .net style events to classes
I've never used .net events/delegates, but from a google search and a subsequent 60 second review of an article on them, they seem to cover the same ground as signals/slots. Am I way off base here?
I quickly googled signals/slots and found a website called http://doc.trolltech.com/3.3/signalsandslots.html
I think Frank was referring to the existing boost signals library. How is your proposal different? Jeff Flinn
Hello, I tried EventHandler library and I found a couple of errors. At beginning of sample/main.cpp there is #include "..\event_handler.hpp" #include "test_class.hpp" but it should be #include <boost/EventHandler.hpp> #include "TestClass.hpp" supposing you compile the example with g++ main.cpp -I path-to-event-handler
From the boost guidelines: "File and directory names must contain only *lowercase* ASCII letters , numbers, underscores, and a period. Leading character must be alphabetic. Maximum length 31. Only a single period is permitted. These requirements ensure file and directory names are relatively portable." thus you should rename your header.
I think you should put your class in boost namespace. In the documentation the title is wrong and in the example the constructor of lonely_class is private (thus you couldn't instantiate it in main) I haven't ever use .Net framework but in general signals/slots and events could live together: indeed, even in Qt there are both. After a short reading, it seems to me that your library performs synchronous function calls: shouldn't events be asynchronous?? Best regards, Manuel Fiorelli
The include directive #include "..\event_handler.hpp" should be fixed with #include "../boost/EventHandler.hpp" Thus the -I option is no longer needed. Best regards, Manuel Fiorelli
participants (3)
-
Jake hall -
Jeff Flinn -
Manuel Fiorelli