[callback abstraction]Determining interest for proposal
I wrote a small library that attempts to abstract function calls. This proved me useful in the following situations: - when I need to find a callback function( lots of if's or big switch ) - when I deal with communication frames with opcodes - several other libraries use callback mechanisms( i.e: dbus ) and brings these advantages: - cleaner code( main objective ) - makes possible to isolate class implementations from the low level call - makes it easy to implement a polymorphism like mechanism Currentely, it's in beta phase. If enough interest is shown, there is surely room for minor improvements. Thanks, Miguel Tadeu
It uses boost::function and boost::bind, among other stuff Sebastian Redl wrote:
I wrote a small library that attempts to abstract function calls. In what way does this library differ from Boost.Function (or
Miguel Tadeu wrote: tr1::function, for that matter)?
Sebastian Redl _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Could you please provide additional information? Does it have anything to do with creating a stack frame dynamically by pushing and popping values for calling functions dynamically? -----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Miguel Tadeu Sent: Thursday, October 18, 2007 10:15 PM To: boost@lists.boost.org Subject: [boost] [callback abstraction]Determining interest for proposal I wrote a small library that attempts to abstract function calls. This proved me useful in the following situations: - when I need to find a callback function( lots of if's or big switch ) - when I deal with communication frames with opcodes - several other libraries use callback mechanisms( i.e: dbus ) and brings these advantages: - cleaner code( main objective ) - makes possible to isolate class implementations from the low level call - makes it easy to implement a polymorphism like mechanism Currentely, it's in beta phase. If enough interest is shown, there is surely room for minor improvements. Thanks, Miguel Tadeu _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
No, nothing to do with that. It uses boost::function and boost::bind, stl::vector and boost::any to create an abstraction to a call. So all your calls look like boost::any call( const vector<boost::any> ¶ms ); Jarrad Waterloo wrote:
Could you please provide additional information? Does it have anything to do with creating a stack frame dynamically by pushing and popping values for calling functions dynamically?
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Miguel Tadeu Sent: Thursday, October 18, 2007 10:15 PM To: boost@lists.boost.org Subject: [boost] [callback abstraction]Determining interest for proposal
I wrote a small library that attempts to abstract function calls. This proved me useful in the following situations:
- when I need to find a callback function( lots of if's or big switch ) - when I deal with communication frames with opcodes - several other libraries use callback mechanisms( i.e: dbus )
and brings these advantages: - cleaner code( main objective ) - makes possible to isolate class implementations from the low level call - makes it easy to implement a polymorphism like mechanism
Currentely, it's in beta phase. If enough interest is shown, there is surely room for minor improvements.
Thanks, Miguel Tadeu _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Ok, a little bit of explanation... Let's follow a real life example that occured to me a while ago. I wrote a piece of software that received a buffer through rs232. I had to interpret that buffer and, depending on the opcode I had to call the right function. Lest's just say there were about 100 different opcodes. Their destination were to several different objects. Solution at that time: - read opcode from the buffer - creat a big switch/case to call the right object::function Switch/case are apopriate if the opcode is not a string, in which case you'll just have 100 if/else if clauses. My solution: - [begining]register each function in a container - [on each communication]pack each parameter in a vector<any> - call get the function by it's opcode(number/string/whatever) and call it Miguel Tadeu Miguel Tadeu wrote:
I wrote a small library that attempts to abstract function calls. This proved me useful in the following situations:
- when I need to find a callback function( lots of if's or big switch ) - when I deal with communication frames with opcodes - several other libraries use callback mechanisms( i.e: dbus )
and brings these advantages: - cleaner code( main objective ) - makes possible to isolate class implementations from the low level call - makes it easy to implement a polymorphism like mechanism
Currentely, it's in beta phase. If enough interest is shown, there is surely room for minor improvements.
Thanks, Miguel Tadeu _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Fri, 19 Oct 2007 17:00:35 +0200, Miguel Tadeu <m_tadeu@yahoo.com> wrote:
Ok, a little bit of explanation...
Let's follow a real life example that occured to me a while ago. I wrote a piece of software that received a buffer through rs232. I had to interpret that buffer and, depending on the opcode I had to call the right function. Lest's just say there were about 100 different opcodes. Their destination were to several different objects.
Solution at that time: - read opcode from the buffer - creat a big switch/case to call the right object::function
Switch/case are apopriate if the opcode is not a string, in which case you'll just have 100 if/else if clauses.
My solution: - [begining]register each function in a container - [on each communication]pack each parameter in a vector<any> - call get the function by it's opcode(number/string/whatever) and call it
Miguel Tadeu
You should give a look at the dispatcher library implemented by Dean Michael Berris. http://www.boost-consulting.com/vault/index.php?action=downloadfile&filename=dispatcher-0.2.zip&directory=& I'm not sure that you've the same goals, but maybe you could collabarate and merging your efforts. :-) Regards, Marco
On 10/19/07, Marco <mrcekets@gmail.com> wrote:
On Fri, 19 Oct 2007 17:00:35 +0200, Miguel Tadeu <m_tadeu@yahoo.com> wrote:
Ok, a little bit of explanation...
Let's follow a real life example that occured to me a while ago. I wrote a piece of software that received a buffer through rs232. I had to interpret that buffer and, depending on the opcode I had to call the right function. Lest's just say there were about 100 different opcodes. Their destination were to several different objects.
Solution at that time: - read opcode from the buffer - creat a big switch/case to call the right object::function
Switch/case are apopriate if the opcode is not a string, in which case you'll just have 100 if/else if clauses.
My solution: - [begining]register each function in a container - [on each communication]pack each parameter in a vector<any> - call get the function by it's opcode(number/string/whatever) and call it
Miguel Tadeu
You should give a look at the dispatcher library implemented by Dean Michael Berris.
I'm not sure that you've the same goals, but maybe you could collabarate and merging your efforts. :-)
This definitely seems like we have the same goals. And the described usage scenario is also similar to what drove me to write the dispatcher library in the first place -- only the earlier motivation was CIMD2 processing. Now though I'm actually using it as a sort-of Front Controller for an HTTP based service I'm working on -- where it holds implementations of the handlers dispatched according to the resource being requested through a URI. The latest code can be gotten from SVN at Sourceforge: http://dispatcher.sourceforge.net/ -- Dean Michael C. Berris Software Engineer, Friendster, Inc. [http://cplusplus-soup.blogspot.com/] [mikhailberis@gmail.com] [+63 928 7291459] [+1 408 4049523]
In deed we have the same goals...seems like you lib does the rest of the work that mine does. You handle the dispatch, I handle the heterogeneous function calls :) Joining the 2 would be great. And would fit my projects either :P. I'm finishing some sample code to show how it works. Probably it's done by the end of the day. I'll post when ready.
I wrote a small library that attempts to abstract function calls. This proved me useful in the following situations:
- when I need to find a callback function( lots of if's or big switch ) - when I deal with communication frames with opcodes - several other libraries use callback mechanisms( i.e: dbus )
and brings these advantages: - cleaner code( main objective ) - makes possible to isolate class implementations from the low level call - makes it easy to implement a polymorphism like mechanism
Currentely, it's in beta phase. If enough interest is shown, there is surely room for minor improvements.
I'm interested. Is there some code I could look at? Regards Hartmut
The sources are available at http://sourceforge.net/projects/abstractcall/ Things I want to change are: - Those macros are pretty crapy, so: - Macros without parameter count( more generic macros ) - Ability to bind with different classes( macros only deal with this ) - Ability to call functions( now it's only calling class methods ) - I dislike storing a pointer in the container - Other stuff is still object of discussion Note that I could use some tips to make these improvements... Miguel Tadeu
participants (7)
-
Dean Michael Berris -
Hartmut Kaiser -
Jarrad Waterloo -
Marco -
Miguel Tadeu -
Miguel Tadeu -
Sebastian Redl