🚀 go-pugleaf

Shalom Reich <sqr1874@acf4.nyu.edu> wrote:

>I don't seem to understand the discussion in this thread.  Yet it seems to generate 
>some strong opinions.  So, . . . 
>
>The routine that will issue the callback (let us call it the driver) needs to use a
>stored pointer.  The argument is that the stored pointer should be to a member function.  
>Why isn't it good enough for the stored pointer to be a pointer to the object and then 
>the driver will only need to say "object->callback();" in order to call the proper routine.
>The usual virtual function semantics would take care of any inheritance hierarchy.

The point is that the "driver" shouldn't have to know the type of the object the
callback is directed at. This is particularly important when the "driver" issuing
the callback is a library API, such as Motif; you do not want the library to have
to know about application data types and you do not want to constrain the application
to use a single callback object type that is defined by the library. The point of the
proposal is that there is a simple extension to the language which would accomplish
this in a type-safe way.

>If the driver could deal directly with the address of a non-static member function 
>how would the "this" parameter be supplied by the caller?

The original article (this has expired on my site and possibly others as well;
maybe I should repost it) suggests a new type "pointer-to-bound-member-function"
which would encapsulate an object pointer and a pointer to a member function
of that class.

>The X example seems to be showing an inteface between a C environment and a C++
>environment.  Is that the real problem?

The real problem is that it's difficult to write an object-oriented API for a
system like X because C++ as currently defined doesn't provide type-independent
object callbacks. The proposed language extension would greatly facilitate the
creation of object-oriented, event-driven API's.

>Am I missing something here?

See my original article for an extended discussion of this issue. I will repost it
or email it if necessary.

Ian Willmott
Bell-Northern Research
Ottawa, Ontario
(613)-763-9688
willmott@bnr.ca
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your 
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu 
]