NetNews Usenet Archive 1992 #26/NN_1992_26.iso/spool/comp/lang/misc/3586

Text File | 1992-11-11 | 3.5 KB | 78 lines

Newsgroups: comp.lang.misc
Path: sparky!uunet!zaphod.mps.ohio-state.edu!darwin.sura.net!spool.mu.edu!news.nd.edu!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubin
From: [e-mail] (Herman Rubin)
Subject: Re: Pointers
Message-ID: <[e-mail]>
Sender: [e-mail] (USENET News)
Organization: Purdue University Statistics Department
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 11 Nov 1992 13:26:18 GMT
Lines: 66

In article <[e-mail]> [e-mail] (Mike Meyer) writes:
>In <[e-mail]>, [e-mail] (Herman Rubin) wrote:
>> In article <[e-mail]> [e-mail] (Mike Meyer) writes:
>> >> You need explicit pointers to functions when the caller does not know
>> >> the name of the function being called, but the caller has received a
>> >> pointer to the function.

>> >No, you don't need *explicit* pointers to functions. It's perfectly
>> >reasonable (and I would argue, preferable) to allow function names
>> >in argument lists.

            ....................

>Herman Rubin finding something difficult to read? That's amazing,
>considering what you call "obvious" code. Maybe it's the lack of
>extraneous characters that serve little or no useful purpose.

I presume that those who like 500-character names :-) might find it
surprising that some people find that hard to read.

>> The way that I would want to use pointers
>> would be to have fl as the pointer to a fill function, and des as the
>> pointer to a descriptor array, of which the first two arguments would
>> be pointers to the current element of the buffer and the bounding position,
>> and then when it is needed make sure that the current element is correct,
>> and issue the call

>>     *fl(*des);

>No problem. That call would look like:

>    fl(*des) ;

>> I will consider any suggestions to do this in a better manner, but I
>> am not willing to make it any less flexible, nor to put any more burdens
>> on the writers of the subprogram, nor of the (usually separately compiled)
>> fill functions.

>You want to make it better? Two things you can do. First, throw away
>the silly attachment to pointers per se, and let the compiler handle
>the trivia. When you call a function with a function as an argument,
>you give it the name of the function as the argument. When you receive
>a function as an argument, you declare it - AND USE IT - as a
>function. That means you can drop the extra "*" on the call, and on
>the reference to the function in the call. No explicit pointers
>needed; they are all implicit, and might not be there at all,
>depending on how good your compiler is.

The function is not an argument to something else.  I do not see how
the code will run any better if we have to use something like

    superfill(*fl,*des)

than what I have suggested.  All superfill would do is to call *fl,
after putting more stuff on the stack, and do some more stack management.
So just as many pointers are used, anyhow.

There is no reason why the caller needs to know the NAME of the function,
in any case.  It is quite possible that even the object code might have
elided the name.  This is even more the case when the program under which
the caller is operating may want to change things at run time.
--
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: [phone]
[e-mail] (Internet, bitnet)
{purdue,pur-ee}!snap.stat!hrubin(UUCP)