To dereference or not dereference,

[KW Heuer]

In article <146 at 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