Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!uwm.edu!lll-winken!elroy.jpl.nasa.gov!ben!richard
From: richard@ben.Jpl.Nasa.Gov (Conan the Barbarian)
Newsgroups: comp.lang.c++
Subject: pointer to function
Keywords: pointer function arguments
Message-ID: <1990Mar19.233906.23149@elroy.jpl.nasa.gov>
Date: 19 Mar 90 23:39:06 GMT
Sender: news@elroy.jpl.nasa.gov (Usenet)
Distribution: usa
Organization: Image Analysis Systems Grp, JPL
Lines: 26

This is an answer to my own posting ( I did some more
digging. Yes, there is a better reference than Stroustrup,
Sun, AT&T, Hansen, and the Waite group for at least this
topic. The Complete C++ Primer by Weiskamp and Flamig is more
expansive. Though Stroustrup's book does have the information
in a cryptic non-standard segment on pointers to member functions.)
You should not pass the address of a member function to
another routine unless the routine is written to
support C++ and specifies an address to a member
function rather than the address of a function.
The method of passing the address is then moot.

Due to the implementation feature of the hidden argument(this),
C++ member function  and C calls are not actually fully compatible 
in their use.

This is not a flame. The use of the member function address
does not make sense when separated from the class instance.
(Yes I can think of a million exceptions also.)
The member function would not fully  operate as documented without
the hidden argument. 

Yuck. That means the handler for a asynchronous server can
not use C++ strategies unless you have all of the server
source also. Double yuck. Who wants to re-write X, Motif,
Xview, Sunview, etc? Triple yuck