home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / cplus / 19892 < prev    next >
Encoding:
Internet Message Format  |  1993-01-25  |  3.2 KB
  1. Xref: sparky comp.lang.c++:19892 comp.std.c++:2120
  2. Path: sparky!uunet!cimshop!davidm
  3. From: davidm@consilium.com (David S. Masterson)
  4. Newsgroups: comp.lang.c++,comp.std.c++
  5. Subject: Callbacks -- suggested approaches??
  6. Message-ID: <DAVIDM.93Jan25171343@consilium.com>
  7. Date: 26 Jan 93 01:13:43 GMT
  8. Sender: root@cimshop.UUCP
  9. Organization: Consilium Inc., Mountain View, California
  10. Lines: 63
  11. X-Posting-Software: GNUS 3.13  [ NNTP-based News Reader for GNU Emacs ]
  12.  
  13. I'm looking for suggestions on how to handle callback functions in C++ that
  14. will be more standard than the one we're currently using.
  15.  
  16. Our application is a distributed system composed of many processes performing
  17. specialized functions.  Each process is represented as a Process object with
  18. specializations derived from this base.  Processes communicate by passing
  19. Message objects that contains any necessary data.  The receiving Process
  20. object looks into the incoming Message, determines its type (a number), and
  21. dispatches it (via table lookup) to a callback function on the Process object
  22. that has been previously registered for that type of Message.  The table where
  23. messages are looked up is (basically) of the following definition:
  24.  
  25.     typedef    void    (Process::*Method)(Message*);
  26.     struct Callback {
  27.         Method        method
  28.         Process*    methodthis;    // could be multi-threaded
  29.     } table[MAXCALLBACKS];
  30.  
  31. Methods would be dispatched like:
  32.  
  33.     void Process::Dispatch(Message* m) {
  34.         return (table[Lookup(m)].methodthis->*
  35.             table[Lookup(m)].method)(m);
  36.     }            
  37.  
  38. The registration method for callbacks looks like:
  39.  
  40.     void Process::Register(Method m, Process* p) {
  41.         table[i].method = m;
  42.         table[i].methodthis = p;
  43.     }
  44.  
  45. and is called like:
  46.  
  47.     mainproc->Register((Method) MYProcess::callback1, myproc);
  48.  
  49. My problem that precipitated this posting was the Method cast in that last
  50. statement.  Our applications could have potentially hundreds of callbacks in
  51. any one process (especially the database interface), so keeping the callbacks
  52. that a process could handle with the process seemed to be a win for
  53. maintenance.  However, that last statement doesn't seem to be a legal one as
  54. callback1 is not necessarily declared as a Method and the explicit cast is
  55. overriding the warning that you would get.  Much of this design was done
  56. originally with a C++ 2.0 compiler, but we are now moving to a C++ 2.1
  57. compiler and trying to clean up the design in the process.  Is there a more
  58. appropriate design for the above (that, hopefully, doesn't mean scrapping
  59. everything)?  I've been looking at the idea of Functors, but that seems like a
  60. maintenance nightmare in that there would be potentially hundreds of
  61. single-function functors lying around in our system (a table lookup seems a
  62. much more straightforward approach).
  63.  
  64. Any ideas?
  65. --
  66. ====================================================================
  67. David Masterson                    Consilium, Inc.
  68. (415) 691-6311                    640 Clyde Ct.
  69. davidm@consilium.com                Mtn. View, CA  94043
  70. ====================================================================
  71. I try to stay away from liberalism.  I know how dangerous it is for
  72. our... Don't ask me to take a liberal position where I am right now.
  73. It's contrary to the administration's viewpoints.  It would not be
  74. terribly helpful to anyone, especially me.
  75.                 -- Vice President Dan Quayle.
  76.