home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / cplus / 13023 < prev    next >
Encoding:
Text File  |  1992-08-29  |  4.3 KB  |  101 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!mcsun!sunic!liuida!isy!isy.liu.se!svan
  3. From: svan@isy.liu.se (Jonas Svanberg)
  4. Subject: Callbacks - C++ needs an extension?
  5. Message-ID: <1992Aug28.165108.17479@isy.liu.se>
  6. Keywords: callback event eventdriven extension
  7. Sender: news@isy.liu.se (Lord of the News)
  8. Reply-To: svan@isy.liu.se
  9. Organization: Linkoping University
  10. Date: Fri, 28 Aug 1992 16:51:08 GMT
  11. Lines: 88
  12.  
  13. Hi guys!
  14.  
  15. Maybe some of you have, like me, done some windowprogramming in
  16. C++. There are a lot of toolkits to choose from, but whatever
  17. you choose, wether it is a C++-package like TNT or a C-package
  18. like xview, you'll probably stumble upon the notion of call-
  19. backs.
  20.  
  21. Callbacks are essencially a functionpointer you deliver to 
  22. the windowing toolkit when creating a widget, for instance 
  23. a button. This function is then supposed to be called when
  24. the user have taken some action, like pressing the button.
  25.  
  26. Their existance is motified by the nature of event-driven
  27. programming and that it is most unpractical to have to edit
  28. sourcecode in the toolkit when you want a special function in
  29. your source to be called.
  30.  
  31. Most often a button is connected to some sort of other
  32. object, like a window, and it is most often the window that
  33. knows how to response when the button is pressed.
  34.  
  35. The problem is that it seems impossible in C++ to implement
  36. a callback strategy which calls this window-object directly...
  37.  
  38. As I see things there are only two (=2) ways to implement callbacks in
  39. C++. Suppose we want to create a Button. A Button is probably 
  40. configurable in many sorts of ways: position, looks, colour and 
  41. more. *BUT* it is when you want to configure the way it 
  42. respondes to a pushdown the trouble begins: 
  43.  
  44. 1) Cloning & modifying.
  45.    You create a Button-object and then modifies it by
  46.    registering your c-style callbackfunction.
  47.    The callback *HAS* to be a static memberfunction or an
  48.    ordinary c-style function (possibly a friend). The only 
  49.    other way I can think of is that a callback itself is an 
  50.    object with a method "exec" or whatever. That just pushes 
  51.    the problem further down the road though.
  52.    The annoying part about this is that your toolkit probably
  53.    has information on both the callback and the object that
  54.    wants it and *still* you can't be called back the 
  55.    proper way (directly instead of through a static stubfunction. 
  56.    C++ just can't offer a portable way to implement such direct 
  57.    callbacks. Why has Borland C++ for Windows extended 
  58.    their language just to handle callbacks from Windows?
  59.  
  60. 2) Creating a new class.
  61.    You create a new Button-derived class where you redefine
  62.    the default buttonPressed-method (virtual). This won't do.
  63.    Probably one has a number of buttons in an application and
  64.    each press will trig some different action. It's a bore
  65.    to create one new class for every button, and if you create
  66.    a reusable Button-derived-class you have the same problem: 
  67.    How to distribute the pushdownevent to the right handler. You
  68.    can't put all handlers inside the button can you?
  69.  
  70. What I really would like is:
  71.  
  72.    To have the possibility to make calls to a memberfunction of
  73.    an object without having to know that objects particular class.
  74.    A sort of blindcall. But this feature could be made safe
  75.    enough. (That is: impossible to fail such a call as long as one
  76.    doesn't use explicit typecasts and the object still exists). It 
  77.    would probably be a first-order object/wrapper: pointer-to-member-
  78.    -of-specifik-type.
  79.    Such a wrapper can be used as an ordinary functionpointer when
  80.    calling but it can't be possible to (implicitely) cast it to one.
  81.    Though the reversed casting should be possible. A function
  82.    which takes a wrapper as an argument should also be able to
  83.    take an ordinary functionpointer as long as the parameter-
  84.    profile is the same. The resulting wrapper could be thought
  85.    of as a membercall to the global environment. 
  86.    Care must be taken when handling such wrappers since they
  87.    just like pointers could be obsolete.
  88.    
  89. All this was thought of when constructing C++ but of some strange 
  90. reason it wasn't included.
  91.  
  92. Anybody agree?
  93.  
  94. --------------------------------------------------------------
  95.  Jonas Svanberg
  96.  Department of Electrical Engineering
  97.  Link÷ping University
  98.  S-581 83 Link÷ping, Sweden             Email: svan@isy.liu.se
  99. --------------------------------------------------------------
  100.  
  101.