Pointers to functions

[Dale Worley]

In article <15859 at ms.maus.de> Kai_Henningsen at ms.maus.de (Kai Henningsen) writes:
   D P Gilbert dpg%extro.ucc.su.OZ.AU @ SUB schrieb am Fr 17.05.1991, 02:18

   DP>Wouldn't it be nice just to
   DP>write the function name without those parentheses (e.g. token.get
   DP>instead of token.get() ). The syntax of C tells me why but could it
   DP>be bent with a #pragma perhaps? 

Well, consider that I have:

	int (*(f(void)))(void);

That is, f is a function that returns a pointer to a function that
returns an integer.  Suppose that f has side-effects, and furthermore
that the functions it returns pointers to have side-effects.

There are now three situations I want to specify:

Referring to f, but not calling it.
Calling f, but not calling the function it returns a pointer to.
Calling f, and then calling the function it returns a pointer to.

In C these are specified as "f", "f()", and "f()()", respectively.
If it weren't for those empty parens, it would be very difficult to
specify these unambiguously.  (Languages that don't use empty parens
to indicate niladic function calls (e.g., Algol 68) have strange rules
to specify where the niladic function calls are implied.  To handle
the above cases, explicit casts would be used.)

Similar problems happen with other uses of pointers to functions.
E.g., how do I subscript an array of function pointers without
automatically calling the function?

On top of all that, in C it is impossible to tell whether a function
is niladic, unless the user has been nice and used prototypes in all
his declarations.

Dale Worley		Compass, Inc.			worley at compass.com
--
"If you could have any amount of money... How much would you want?"
"All of it."