stuart@tartarus.uchicago.edu (Stuart A. Kurtz) (09/01/89)
I've been implementing a DA in MPW C using an object-oriented approach. To
handle methods, I store in an object record the difference between a fixed
procedure and the desired procedure. I then recover the procedure by
adding the address of the fixed procedure back. Why all the hassle? Well,
the DRVR resource may move behind my back, and I'm not willing to either
lock it (so un-macish), or to recompute all my addresses on each reentry
(so inefficient). I'm an academic -- I'm *allowed* to be fastidious.
Now, MPW C makes this difficult in two ways.
First, the following isn't accepted:
typedef int (*PFI)();
int PFI2Int(PFI p)
{
return p - PFI2Int;
}
The complier complains about munging function pointers. It's not happier
about the inverse transformation:
PFI Int2PFI(int a)
{
return PFI2Int + a;
}
Adding an ampersand in front of the PFI2Int's shouldn't help, and it
doesn't. There is a workaround -- cast the PFI's to int and conversely --
but the original code is legit C.
Second, because the methods take arguments that are idiosyncratic to the
method, the only *simple* type description that accurately describes them
involves an ellipsis, e.g.:
/* PFV == pointer to function returning void. */
typedef void (*PFV)(...);
Now, MPW C barfs on this (you might too, although for different reasons).
Again, there is a workaround, using an "old" C declaration:
typedef void (*PFV)();
But this is only accurate for "wild" types. I really want
typedef (*EventHandler)(DAObject**,...);
I won't *swear* this is legitimate ANSI C, as K&R (2nd edition) don't have
an example that looks like this (we all *know* that C is defined by
example), but they don't rule it out, either.
I really can't be upset by these glitches in an otherwise nice compiler:
there are fairly obvious workarounds, and I'll admit that the code is
obscure. I can, however, note them...
Stud88-jwa@nada.kth.se (Jon W{tte) (09/01/89)
In article <5261@tank.uchicago.edu> stuart@tartarus.uchicago.edu (Stuart A. Kurtz) writes: [ Problems with function pointers ] >doesn't. There is a workaround -- cast the PFI's to int and conversely -- >but the original code is legit C. I would suggest (long) of course, since (int) is 16 bits in many Mac compilers. Also, addition of pointers is not allowed in C (Just look at the previous flame-war in comp.lang.c |-( ) Addition of longs representing addresses MIGHT work on the mac for the forseeable future (providing, of course, that you use StripAddress) Happy Hacking -- This is your fortune from h+@nada.kth.se: Excellent time to become a missing person.