Re: Object oriented callbacks and differences in member vs non-member function pointers
On Jun 8, 2:23 pm, Faraz Babar <fba...@gmail.com> wrote:
I have great respect for the contributors of this newsgroup and have a
question that I can't seem to find an answer for, I need to understand
if it there is anything in the C++ standard that prevents or dictates
how compilers implement function pointers for stand alone versus
member functions. Completely ignoring ABI and name mangling issues
here, one would imagine that the underlying address or function
pointer for member and non member functions would be identical in size
(surely it would be a word whose size won't change for a given
platform). My question is can we rely on this equivalence (in size of
function pointers for members versus non member function)? The reason
for asking this question is to find out if the following trick would
work portably without running afoul of C++ standard or not:
C++ offers no standard way to obtain the address of a member function
in the first place, so the question about the characteristics of such
a pointer is essentially moot.
Let's declare a structure as follows:
union call_back
{
void (thread::*filler)();
void * (*address)(void *);
} routine;
This structure allows us to store the address of a member function of
class thread in routine.filler, while allowing us to pass
routine.address (to pthread_create() for example) as a callback
function with a non-member signature.
No, this union allows a program to use one data structure to store,
alternately a function pointer, or a member function pointer - which -
despite its name is not (or not exclusively) a function - but is
instead an encoding of whatever information is needed to invoke a
particular class method given an object of a particular class. So not
only would a member pointer need the address of the method, it would
probably also have to store whatever adjustments need to be made to
the object pointer into order to invoke the stored method with the
appropriate "this" argument.
The questions are: 1. Is there a
better way to pass a member function address where the underlying
library expects a non-member signature, perhaps a better way of
casting a member function pointer to non-member function pointer and
2. Are there cases where this approach may break?
Of course. Any time this "technique" is employed, it may not work -
even if it worked upon every prior occassion with the same program
binary. No assumptions can be made when undefined behavior is invoked
- which makes any program with undefined behavior little better than
useless.
Before you recommend using a static member function or non-member
dispatcher as a solution, I know about those, what I am trying to
achieve is stay object oriented in my callback framework:
There is nothing about passing a pointer to an object to a routine
(including a callback) and then having that routine invoke a method on
the passed object, that somehow violates "object-orientedness" - on
the contrary, C++ program routinely pass objects by pointer or
reference to routines which then call class methods on the passed
object.
Furthermore, the API that this implementation must conform to is the
pthread API - which already dictates what a suitable argument for a
callback must be. A program is not at liberty to rewrite the pthread
API to one that it might prefer - it must instead use the API
provided.
If the above reasons are not enough to persuade you, then consider
that there is nothing "elegant" about unions - and most C++
programmers routinely avoid them. Furthermore, I would venture to say
that no C++ programmer would ever be willing to entrust their program
to this technique - no matter how many assembly listings were produced
to show that it was OK. In short, if every response to a post gives
the same advice - you have orchestrated a rare moment of unanimity in
this forum :-) - but more importantly, you may trust that the advice
provided is sound.
Greg
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]