🚀 go-pugleaf

I think this whole thread is incredibly silly.

C's function pointers are almost exactly like the procedure variables that
many other languages have.  As in many other aspects, C has overloaded an
available syntax and used it for some other meaning.  Thus, in C, a
function declaration where the name is preceded by a "*" indicates that
it's a variable that can be assigned dynamically rather than a name that
should be linked.  This is analogous to PL/I's requirement that a procedure
variable declaration have the keyword "variable" in it.

Outside the declaration, you don't even have to think of it as a pointer.
All uses of function pointers act just like they do in languages with
procedure variables: assignments reassign the variable, while using it in a
function call syntax causes the referenced function to be called.

C function pointers aren't like any other pointers in the language.  You
can't do pointer arithmetic on them.  You're not allowed to indirect
through one except when it's in a function call syntax, and in the latter
case the indirection isn't required.  You can't cast between them and
non-function pointers.

One difference between C and most of the other languages with procedure
variables is that C doesn't have nested procedures.  In the other
languages, a procedure variable generally includes both a code pointer and
an environment (in the traditional languages, which don't allow nested
procedures to be returned, this is usually a stack frame pointer).  C
doesn't require environments to be associated with functions because
they're all defined in the global environment, so the C designers could
simply implement procedure variables as pointers to the actual code, and
they specified the declaration syntax accordingly.  But when you look at
C++ and its member function pointers, you see that these are more like the
traditional procedure variables (the environment in this case is the "self"
object); however, they've kept C's function "pointer" syntax for declaring
them.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar