NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/windows/openloo/3640

Text File | 1992-08-29 | 3.9 KB | 91 lines

Newsgroups: comp.windows.open-look
Path: sparky!uunet!mcsun!sunic!liuida!isy!isy.liu.se!svan
From: [e-mail] (Jonas Svanberg)
Subject: Re: Q: C++ and callback problems.
Message-ID: <[e-mail]>
Sender: [e-mail] (Lord of the News)
Reply-To: [e-mail]
Organization: Linkoping University
References: <[e-mail]>
Date: Fri, 28 Aug 1992 16:15:56 GMT
Lines: 78

> In article [e-mail], [e-mail] (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        [e-mail]
> 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
 Link÷ping University
 S-581 83 Link÷ping, Sweden             Email: [e-mail]
--------------------------------------------------------------