Re: quik popularized by ANSI C
From: Arthur J. O'Dwyer (ajo_at_nospam.andrew.cmu.edu)
Date: 06/14/04
- Next message: Evangelista Sami: "memory optimization"
- Previous message: Peter Mount: "Re: Trouble with scanf("%c", &answer);"
- In reply to: Jack Klein: "Re: quik popularized by ANSI C"
- Next in thread: J. J. Farrell: "Re: quik popularized by ANSI C"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 14 Jun 2004 09:37:59 -0400 (EDT)
On Sun, 13 Jun 2004, Jack Klein wrote:
>
> On Sun, 13 Jun 2004 22:42:13 +0100, "Malcolm" wrote:
> > "Jack Klein" <jackklein@spamcop.net> wrote in message
> > >
> > > What is unfortunate about it?
> >
> > It is a bit silly that
> >
> > int (*fptr) (int);
> >
> > fptr = afunction;
> >
> > x = (*fptr) (1) ;
> > y = fptr(1);
> >
> > as exactly the same effect. Of course a function is not a variable, so
> > dereferencing a function pointer is not exactly meaningful.
I think it's a quirk, but it has a very good purpose. I generally
try to keep "redirectable function pointer" and "immutable function" as
two separate concepts where useful; thus, I follow Declaration-Mimics-Use
with pointers
int (*fptr)(int);
x = (*fptr)(42);
and functions
int func(int);
y = func(42);
unless I have a darn good reason not to.
> Why is that any sillier than:
>
> int some_func(const char*);
>
> char ch [] = "Hello";
> some_func(ch);
> some_func(&ch[0]);
> ...have exactly the same effect?
Count the levels of indirection.
ch --- 0 levels
&ch[0] --- 0 levels
fptr --- 0 levels
*fptr --- 1 level
The former pair (Jack's example) have the same effect because they
designate the same object with the same number of levels of indirection.
The latter pair (Malcolm's example) have the same effect *despite*
different levels of indirection. In fact, as van der Linden points
out,
*****fptr --- 5 levels
has --- almost --- exactly the same value and semantics as 'fptr'
(0 levels).
Now, why is this? Simple: like array names, function names "decay"
into function pointers in value contexts. Thus, while 'func' is a
function, '*func' is "the-function-pointed-to-by-the-decayed-function-
pointer-'func'." That is, it's exactly the same function. And then
since '*func' is a function, obviously we can recurse: '**func' is
the function pointed to by the pointer we get by decaying '*func';
'***func' and '****func' and '*********func' are exactly the same
function.
The "--- almost ---" above is a nod to the fact that when 'fptr'
is a function pointer, then 'sizeof fptr' yields the size of the
function pointer type; but 'sizeof *fptr' (and 'sizeof '*****fptr')
try to evaluate the size of an actual function type, which is not
allowed by the rules of the C language. Thus the expressions 'fptr'
and '*fptr' behave differently in the context of 'sizeof' (and also
in the context of '&', where '&*fptr' is 'fptr' itself, but '&fptr'
is the address of the pointer object 'fptr').
As array names do not decay to array pointers, but rather to pointers
to their first elements, there is no "corresponding quirk" with respect
to arrays. I don't know what van der Linden was talking about, there,
but perhaps you ought to read the next few pages; I bet he explains his
statement. I'll check next time I see the book.
HTH,
-Arthur
- Next message: Evangelista Sami: "memory optimization"
- Previous message: Peter Mount: "Re: Trouble with scanf("%c", &answer);"
- In reply to: Jack Klein: "Re: quik popularized by ANSI C"
- Next in thread: J. J. Farrell: "Re: quik popularized by ANSI C"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
