Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 ggr 10/10/85; site bentley.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!bentley!kwh
From: kwh@bentley.UUCP (KW Heuer)
Newsgroups: net.lang.c
Subject: Re: To dereference or not dereference,
Message-ID: <651@bentley.UUCP>
Date: Wed, 19-Mar-86 10:21:27 EST
Article-I.D.: bentley.651
Posted: Wed Mar 19 10:21:27 1986
Date-Received: Fri, 21-Mar-86 04:00:36 EST
References: <196@aplvax.UUCP> <2600040@ccvaxa>, <146@sdchema.sdchem.UUCP>
Organization: AT&T Bell Laboratories, Liberty Corner
Lines: 30

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