🚀 go-pugleaf

References: <4h9ii0$3mlq@news-s01.ny.us.ibm.net>

hickeyr@ibm.net (Rich Hickey) wrote:

>Having previously considered the suggestion you proposed and forced to solve 
>the problem in current language, and with a lot of experience using a
>current-language solution, I feel it is actually preferable to the extension 
>you propose in the following areas:
>
>A)It is more type-flexible. By that I mean it is possible to produce a 
>callback system that is type-safe, yet tolerant of type differences in the 
>caller/callee signatures that are either implicitly convertible or can be 
>ignored. For example if the caller requires a function to which it can pass 
>an int and from which it expects nothing, using my library it is possible to 
>bind the callback to a function that takes an int and returns an int (return 
>value is ignored), or takes a long and returns void (compiler implicitly 
>converts int->long). Once you get involved with polymorphism this becomes 
>critical: caller passes ptr-to-derived, callee accepts ptr-to-base. Any 
>language extension approach would have the rigidity normally associated with 
>pointers-to-functions, i.e. exactly matching signatures required. 

I'm not sure what you mean by this. I've never heard of any requirement
for "exactly matching signatures" for calls through pointers-to-function.
As far as I know the matching rules are exactly the same as for ordinary
function calls. The following code is accepted by Cfront v3.0
without complaint:

class A {
    int x;
};

class B: public A {
    int y;
};

int (*fp)(long,A *);

long func(int i,B *p)
{
    return(fp(i,p));
}

The proposed language extension would work the same way. It's true
that this is illegal (I assume this is what you were referring to):

fp=&func;  // never mind the infinite recursion here

However, I don't see why this is a problem. You just declare your
callback functions to take the most general parameters; in this
example, (long,A *) instead of (int,B *). The proposed type
"pointer-to-bound-member-function" is the natural analog for class
member functions of the existing pointer-to-function type, and will
be useful in the same contexts.

>B)It is easier to extend; to things like callbacks with stored arguments 
>etc.

How so? Here's the PBMF solution:

class MyCallback {
    int (class::*pbmf)(int,A *);  // language extension
    int i;
    A *p;
public:
    MyCallback((class::*pb)(int,A *),int ii,A *pp):
        pbmf(pb),i(ii),p(pp) {}
    int operator()
        { return(pbmf(i,p)); }
};

No dynamic allocation, virtual functions, casts to void *, or templates
(although you could use them if you wanted to) needed. Of course, if this
extension were adopted, this would not prevent other solutions from being
used anywhere they were appropriate. For most cases, the built-in datatype
is more convenient and type-safe.

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 
]