🚀 go-pugleaf

In <BxJzzv.4H7@mentor.cc.purdue.edu>, hrubin@pop.stat.purdue.edu (Herman Rubin) wrote:
> In article <mwm.2lp7@contessa.palo-alto.ca.us> mwm@contessa.palo-alto.ca.us (Mike Meyer) writes:

This all started when herman said:
> >> >> 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.

> >> 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.

Herman, the code probably won't _run_ any better. It will never run
any worse, as a "dumb" implementation would map it directly back to
the pointers you used. The point is that your original statement -
about needing explicit pointers - is _wrong_. I know it's wrong; I do
just what you're talking about in a language with no explicit pointers
all the time. The original code I posted showed such a case exactly. I
apologize for using identifiers that made things clearer instead of
your favorite one-letter-with-no-relation-to-the-problem style.

> So just as many pointers are used, anyhow.

That's for the dumb compiler, or the worst-case for the smart
compiler. By getting rid of the explicit pointers, you make it
possible for a compiler to notice cases where all the functions being
passed in are known, and to generate better code to take advantage of
that.  In the extreme case, only one such function is used, and a good
compiler will generate inline code for it.

	<mike