From: svan@isy.liu.se (Jonas Svanberg)
Subject: Re: Q: C++ and callback problems.
Reply-To: svan@isy.liu.se
Organization: Linkoping University
Date: Fri, 28 Aug 1992 16:15:56 GMT

> In article Gq7@solbourne.com, imp@solbourne.com (Warner Losh) writes:
> If you really want to use member function callbacks (especially
> virtuals), you should be using a C++ based toolkit.  It makes life so
> much easier.  There are some commercial ones, plus some freely
> distributable ones.  They make your life much simpler than trying to
> kludge around the problem in a C based toolkit.

> Warner

> P.S.  You all should realize that I'm slightly biased on this issue. :-) 
> -- 
> Warner Losh		imp@Solbourne.COM
> I've almost finished my brute force solution to subtlety.

How then do these toolkits handle callbacks/events?

As I see things there are only two ways. Suppose we want to create a
Button. A Button is probably configurable in many sorts of ways:
position, looks, colour and more. *BUT* it is when you want to 
configure the way it respondes to a pushdown the trouble begins: 

1) Cloning & modifying.
   You create a Button-object and then modifies it by
   registering your c-style callbackfunction.
   The callback *HAS* to be a static memberfunction or an
   ordinary c-style function (possibly a friend). The only 
   other way I can think of is that a callback itself is an 
   object with a method "exec" or whatever. That just pushes 
   the problem further down the road.
   The irritating part about this is that your toolkit probably
   has information of both the callback and the object that
   wants it and *still* you can't be called back the 
   proper way. C++ just can't offer a portable way to implement 
   such direct callbacks. Why has Borland C++ for Windows extended 
   their language just to handle callbacks from Windows?

2) Creating a new class.
   You create a new Button-derived class where you redefine
   the default buttonPressed-method (virtual). This won't do.
   Probably one has a number of buttons in an application and
   each press will trig some different action. It's a bore
   to create one new class for every button, and if you create
   a reusable Button-derived-class you have the same problem: 
   How to distribute the pushdownevent to the right handler. You
   can't put all handlers inside the button can you?

What I really would like is:

   To have the possibility to make calls to a memberfunction of
   an object without having to know that objects particular class.
   A sort of blindcall. But this feature could be made safe
   enough. (That is: impossible to fail such a call as long as one
   doesn't use explicit typecasts and the object still exists). It 
   would probably be a first-order object/wrapper: pointer-to-member-
   -of-specifik-type.
   Such a wrapper can be used as an ordinary functionpointer when
   calling but it can't be possible to (implicitely) cast it to one.
   Though the reversed casting should be possible. A function
   which takes a wrapper as an argument should also be able to
   take an ordinary functionpointer as long as the parameter-
   profile is the same. The resulting wrapper could be thought
   of as a membercall to the global environment. 
   Care must be taken when handling such wrappers since they
   just like pointers could be obsolete.
   
All this was thought of when constructing C++ but of some strange 
reason it wasn't included.


Anybody agree?

--------------------------------------------------------------
 Jonas Svanberg
 Department of Electrical Engineering
 Linkping University
 S-581 83 Linkping, Sweden             Email: svan@isy.liu.se
--------------------------------------------------------------

Xref: sparky comp.windows.open-look:3596 comp.windows.x:15619