aglew@ccvaxa.UUCP (03/13/86)
>/* Written 4:55 pm Mar 6, 1986 by kwh@bentley.UUCP in ccvaxa:net.lang.c */ >In article <44@umcp-cs.UUCP> umcp-cs!chris (Chris Torek) writes: >> int f(), (*p)(); >> p = f; >> p(1); >> (*p)(2); >> (**p)(3); >> (****************p)(4); > >Although there is no excuse for "p(1)", the other three examples are >in fact correct. Recall that there are only two things you can do >with a function (not a pointer): call it (as in f()) or take its >address (any other use of the name). Thus "p = f" takes the address >of function f and stores it in pointer p. According to what I've heard about the ANSI C standard, "p(1)" is permitted, with a half-decent reason behind it. C does not let you have segmented names for functions. This way you can get them: struct { int (*draw)(); } graph; graph.draw = my_favorite_draw_function; graph.draw(); /* is equivalent to */ (*graph.draw)(); graph.draw is slightly cleaner, although more confusing. Now, if we could just initialize a function pointer with the address of an in-line lambda function.
kwh@bentley.UUCP (KW Heuer) (03/19/86)
In article <146@sdchema.sdchem.UUCP> sdchem!tps (Tom Stockfisch) writes: >I always use > int (*p)(); > ... > p(); >as I think of the call as dereferencing the function pointer, and complicated >calls have one less level of parentheses for your eyes to wade through. True, but I'd rather write what I mean instead of having the compiler automatically compensate. With this convention, you can't determine without context whether p is a function or a pointer to one. >Also, you can often less painfully add an option to a program by >redefining a function as a function pointer and having 2 (or more) >versions of the function. [ Example deleted ] One could apply the same logic to, say, structure pointers, and argue that instead of having the "->" notation, "p.foo" should be interpreted as "(*p).foo" if p is a pointer to a structure. In fact, K&R could've made structures work the same way as functions and arrays, with the only valid structure operations being "." and (implicit) "&". Then when somebody came up with the bright idea of structure (copy|(call|\ return) by value), they would find it impossible to implement without breaking every program. Granted, functions as objects are not as useful as structures, But I think consistency is an important feature in a language, so I would prefer to have neither dereferencing nor rereferencing be automatic. Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint