home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / lang / cplus / 18915 < prev    next >
Encoding:
Internet Message Format  |  1993-01-10  |  2.3 KB
  1. Path: sparky!uunet!usc!news.cerf.net!nic.cerf.net!hlf
  2. From: hlf@nic.cerf.net (Howard Ferguson)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Callbacks in C++
  5. Date: 11 Jan 1993 03:46:33 GMT
  6. Organization: CERFnet Dial n' CERF Customer Group
  7. Lines: 45
  8. Message-ID: <1iqqipINN11b@news.cerf.net>
  9. References: <1iikcuINN6fr@news.cerf.net> <rmartin.726677907@thor>
  10. NNTP-Posting-Host: nic.cerf.net
  11.  
  12. In article <rmartin.726677907@thor> rmartin@thor.Rational.COM (Bob Martin) writes:
  13. >hlf@nic.cerf.net (Howard Ferguson) writes:
  14. >
  15. >>The FAQ for this group describes how to put wrapper functions around 
  16. >>member functions so they can be called as callbacks from X libraries
  17. >>and the like. But if I am writting a c++ class library, surley I should
  18. >>be able to provide a cleaner mechanism to my customers. Is there
  19. >>a standard way of doing this???
  20. >
  21. >If you are designing a class library, you don't generally want to
  22. >provide callbacks to your users.  Instead, you want to provide them
  23. >with interfaces that they can use to receive information from you.
  24. >These interfaces are abstract classes.  Pure virtual functions are
  25. >declared which allow information to be passed from your class library
  26. >to user objects derived from the abstract classes.  The users can
  27. >implement the derivatives of the pure virtuals as they see fit.
  28. >
  29. Does this derived function not just end up being a large
  30. switch statement -- which is exactly what you are trying to avoid.
  31. For example if the user has a display object with 2 members save_screen()
  32. and zoom_screen(). When the buttons for these pieces of functionality
  33. are created the application wants to tell the button that when it is
  34. selected then the save_screen() function should be called.
  35.  
  36. If I derive from the ButtonCallback (supplied by the class library)
  37. then I presume I will have to overwrite the ButtonHasBeenClicked() 
  38. function which is a member of the ButtonCallback to do something like 
  39. this 
  40.  
  41. UserButtonCallback::ButtonHasBeenClicked(Buttonvoid *userInfo)
  42. {
  43.     switch (userInfo) {
  44.     case SAVE : display->save_screen();
  45.             break;
  46.  
  47.     case ZOOM : display->zoom_screen();
  48.             break;
  49. }
  50.  
  51. I can see where your suggestion of deriving from a pure virtual would
  52. be very useful in the situation where the number and types of 
  53. callbacks are restricted -- but does it provide any easy way of getting
  54. the functionality required for the example just given ???????
  55.  
  56.     hlf
  57.