bhoughto@pima.intel.com (Blair P. Houghton) (05/16/91)
In article <1512@caslon.cs.arizona.edu> dave@cs.arizona.edu (Dave Schaumann) writes: >You have found one of the weirdnesses of ANSI-C. When you have a pointer >to a function, you (normally) invoke the function by saying > (*funptr)() >However, ANSI, in it's infinite wisdom, decided that you should be able to >say > funptr() >in the same context, with similar results. It's not weird at all. It's rather consistent. The actual syntax is <expression>(<optional list of arguments>) where the expression must evaluate to a function pointer. A similar thing is true of arrays, structs, and unions, where the syntaxes are <expression>[<expression>] <expression>.<member name> <expression>-><member name> The only thing remotely weird about it is that now `funptr' and `*funptr' are the same thing, but that's why function poiners are often singled out for different semantic treatment in the standard (many things you can do with a pointer to int are forbidden with a function pointer). --Blair "Many things you can do with your own nose are forbidden with your neighbor's."
dpg@extro.ucc.su.OZ.AU (D P Gilbert) (05/17/91)
bhoughto@pima.intel.com (Blair P. Houghton) writes: >In article <1512@caslon.cs.arizona.edu> dave@cs.arizona.edu (Dave Schaumann) writes: >>You have found one of the weirdnesses of ANSI-C. When you have a pointer >>to a function, you (normally) invoke the function by saying >> (*funptr)() >>However, ANSI, in it's infinite wisdom, decided that you should be able to >>say >> funptr() >>in the same context, with similar results. >It's not weird at all. It's rather consistent. The actual >syntax is > <expression>(<optional list of arguments>) >where the expression must evaluate to a function pointer. >A similar thing is true of arrays, structs, and unions, where >the syntaxes are > <expression>[<expression>] > <expression>.<member name> > <expression>-><member name> >The only thing remotely weird about it is that now `funptr' >and `*funptr' are the same thing, but that's why function >poiners are often singled out for different semantic >treatment in the standard (many things you can do with >a pointer to int are forbidden with a function pointer). As I reach for the shift button to put yet another set of left and right parentheses after a niladic function call I have begun to wonder how to relieve such tedium. Wouldn't it be nice just to write the function name without those parentheses (e.g. token.get instead of token.get() ). The syntax of C tells me why but could it be bent with a #pragma perhaps? Whenever I want the address of a function I use "&" so I can understand my code 18 months later. I know this amounts to heresy ... apologies in advance Doug Gilbert
bhoughto@pima.intel.com (Blair P. Houghton) (05/18/91)
In article <dpg.674453898@extro> dpg@extro.ucc.su.OZ.AU (D P Gilbert) writes: >Wouldn't it be nice just to write the function name >without those parentheses (e.g. token.get instead of >token.get() ). >I know this amounts to heresy ... apologies in advance Ob. response: If you want Pascal, you know where to find it. --Blair "I don't want it, and come to think of it, I don't know where to find it..."
enag@ifi.uio.no (Erik Naggum) (05/20/91)
D P Gilbert writes: | | As I reach for the shift button to put yet another set of left and | right parentheses after a niladic function call I have begun to | wonder how to relieve such tedium. Wouldn't it be nice just to | write the function name without those parentheses (e.g. token.get | instead of token.get() ). The syntax of C tells me why but could | it be bent with a #pragma perhaps? Whenever I want the address of | a function I use "&" so I can understand my code 18 months later. Assuming struct ... { ... void (*get)(); ... } token; token.get() is a function call by virtue of the "()", while token.get is the value of the function pointer. Remember that statements such as 3; are legal in C, but sort of pointless. token.get; is no exception. Other languages don't know about function pointers and can alleviate the user of the power thereof. </Erik> -- Erik Naggum Professional Programmer +47-2-836-863 Naggum Software Electronic Text <enag@ifi.uio.no> 0118 OSLO, NORWAY Computer Communications <erik@naggum.uu.no>